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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the principles of interworking between the 3GPP IM CN subsystem and BICC/ISUP 
based legacy CS networks, in order to support IM basic voice, data and multimedia calls. 

The present document addresses the areas of control and user plane interworking between the IM CN subsystem and CS 
networks through the network functions, which include the MGCF and IM-MGW. For the specification of control plane 
interworking, areas such as the interworking between SIP and BICC or ISUP are detailed in terms of the processes and 
protocol mappings required for the support of both IM originated and terminated voice and multimedia calls. 

Other areas addressed encompass the transport protocol and signalling issues for negotiation and mapping of bearer 
capabilities and QoS information. 

The present document specifies the interworking between 3GPP profile of SIP (as detailed according to 3GPP TS 
24.229 [9]) and BICC or ISUP, as specified in ITU-T Recommendations Q.1902.1 to Q.1902.6 [30] and ITU-T Q761 to 
Q764 [4] respectively. 

The present document also specifies the interworking between circuit switched multimedia telephony service, as 
described in 3GPP TS 26.1 10 [78] 3GPP TS 26.1 II [79], and ITU-T Recommendation H.324 [81] and packet switched 
multimedia services, as described in 3GPP TS 26.235 [80] and 3GPP TS 26.236 [32], in particular and the interworking 
between the 3GPP profile of SIP and the inband control protocols for multimedia communication as specified in ITU-T 
Recommendations H.245 [82] and H.324 Annex K [81]. 

The present document addresses two interworking scenarios with respect to the properties of the CS network: 

The CS network does not use any 3GPP specific additions. 

- The CS network uses 3GPP specific additions. 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [6], ITU-T 
Recommendation E. 164 [48] and the following apply: 

Carrier textphone mode: a mode for text communication, where continuous signals (i.e. a carrier tone) are present on 
the connection irrespective of whether text is being exchanged or not. 

Carrierless textphone mode: a mode for text communication, where signals are only present on the connection when 
text is being exchanged. E.g.: Baudot 
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SS7 signalling function: function in the CS network, which has the capabilities to transport the SS7 MTP-User parts 
ISUP and BICC+STC„,p 

SIP signalling function: function in the IM CN subsystem, which has the capabilities to transport SIP 

Incoming or Outgoing: used in the present document to indicate the direction of a call (not signalling information) 
with respect to a reference point. 

Incoming MGCF (I-MGCF): entity that terminates incoming SIP calls from the IMS side and originates outgoing calls 
towards the CS side using the BICC or ISUP protocols. 

Outgoing Interworking Unit (O-MGCF): entity that terminates incoming BICC or ISUP calls from the CS side and 
originates outgoing calls towards the IMS using SIP. 

Root Termination: refers to Media Gateway as an entity in itself, rather than a Termination within it. A special 
TerminationID, "Root" is reserved for this purpose. See ITU-T Recommendation H.248.1. [2] 

Signalling Transport Converter (STC): function that converts the services provided by a particular Signalling 
Transport to the services required by the Generic Signalling Transport Service. 

STCmtp: Signalling Transport Converter on MTP. See ITU-T Recommendation Q.2150.1 [29]. 

BICC+STCmtp: this terminology means that BICC signaling always need to be used on top of STCmtp sublayer. 



3.2 



Abbreviations 



For the purposes of the present document, the abbreviations as defined in 3GPP TR 21.905 [6] and the following apply: 



3PTY 

AALl 

ACR 

ANM 

APM 

APRI 

ATP 

BC 

BCI 

BGCF 

BICC 

CB 

CCNR 

cess 

CDa 

CDi 

CDIV 

CdPN 

CFB 

CFNR 

CGB 

CgPN 

CIC 

CMR 

CON 

CONF 

COT 

CPC 

CPG 

CSI 

DSCP 

FAC 

FQC 

GN 

GRS 



Three Party 

ATM Adaptation Layer type 1 

Anonymous Call Rejection 

ANswer Message 

Application Transport Message 

Address Presentation Restriction Indicator 

Access Transport Parameter 

Bearer Capability 

Backward Call Indicators 

Breakout Gateway Control Function 

Bearer Independent Call Control 

Communication Barring 

Call Completion on No Reply 

Call Completion Service Set-up 

Call Deflection Alerting 

Call Deflection Immediate 

Communication Diversion 

Called Party Number 

Call Forwarding Busy 

Call Forwarding No Reply 

Circuit Group Blocking 

Calling Party Number 

Carrier Identification Code 

Codec Mode Request 

Connect 

Conference 

Continuity 

Calling Party's Category 

Call ProGress message 

Carrier Selection Information 

DiffServ Code Point 

Facility 

Frame Quality Classification 

Generic Number 

Group Reset 
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GVNS Global Virtual Network Service 

H/W Hardware 

IDR Identification Request 

lEPS International Emergency Preference Scheme 

I-MGCF Incoming MGCF 

IM-MGW IP Multimedia Media Gateway Function 

INF Information 

INR Information Request 

IRS Identification Response 

ITCC International Telecommunication Charge Card 

ITU-T International Telecommunication Union - Telecommunication Standardization Sector 

MCID Malicious Communication Identification 

M3UA MTP-L3 User Adaptation layer 

MLPP Multi-Level Precedence and Pre-emption 

MONA Media Orientation Negotiation Acceleration 

MPC Media Preconfigured Channel 

MRFP Media Resource Function Processor 

MSN Multiple Subscriber Number 

MSU Message Signalling Unit 

MWI Message Waiting Indication 

NOA Nature Of Address 

NPDI Number Portability Database Dip Indicator 

OIP Originating Identification Presentation 

OIR Originating Identification Restriction 

OLI Originating Line Information 

O-MGCF Outgoing MGCF 

PI Progress Indicator 

PIDF Presence Information Data Format 

REV Reverse Charging 

RLC Release Complete 

RSC Reset Circuit 

RTCP RTP Control Protocol 

SAM Subsequent Address Message 

SCTP Stream Control Transmission Protocol 

SGW Signalling Gateway 

SPC Signalling Preconfigured Channel 

ST Sending Terminated 

TCAP Transaction Capabilities Application Part 

TDM Time Division Multiplex 

TIP Terminating Identification Presentation 

TIR Terminating Identification Restriction 

TMR Transmission Medium Requirement 

TMU Transmission Medium Used 

TNL Transport Network Layer 

TNS Transit Network Selection 

TP Terminal Portability 

UA User Agent 

UAC User Agent Client 

UDI Unrestricted Digital Information 

UDI-TA Unrestricted Digital Information with Tones/ Announcemnets 

URI Uniform Resource Identifier 

USI User Service Information 

UUS User-to-User Signalling 

XML extensible Markup Language 
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4 General 

4.1 General interworking overview 

The IM CN subsystem shall interwork with BICC and ISUP based legacy CS networks, e.g. PSTN, ISDN, CS PLMNs, 
in order to provide the ability to support basic voice calls (see 3GPP TS 22.228 [11]), between a UE located in the IM 
CN subsystem and user equipment located in a CS network. 

For the ability to support the delivery of basic voice calls between the IM CN subsystem and CS networks, basic 
protocol interworking between SIP (as specified in 3GPP TS 24.229 [9]) and BICC or ISUP (as specified in ITU-T 
Recommendations Q. 1902. 1-6 [30] and ITU-T Recommendations Q761 to Q764 [4] respectively) has to occur at a 
control plane level, in order that call setup, call maintenance and call release procedures can be supported. The MGCF 
shall provide this protocol mapping functionality within the IM CN subsystem. 

User plane interworking between the IM CN subsystem and CS network bearers (e.g. 64k TDM, ATM/AAL2 circuit or 
IP bearer) are supported by the functions within the IM-MGW. The IM-MGW resides in the IM CN subsystem and 
shall provide the bearer channel interconnection. The MGCF shall provide the call control to bearer setup association. 

The IM CN subsystem shall interwork, at the control and user plane, with BICC and ISUP based legacy CS networks. 
The support of supplementary services shall be as defined in 3GPP TS 22.228 [11]. The MGCF and IM-MGW shall 
support the interworking of the IM CN subsystem to an external ISUP based CS network. They may also support 
interworking to a BICC based CS network where no 3GPP specific extension is applied. The MGCF and the IM-MGW 
may also support interworking to a BICC based CS network where 3GPP specific extensions in accordance with 3GPP 
TS 29.205 [14] are applied. 



5 Network characteristics 

5.1 Key characteristics of ISUP/BICC based CS networks 

This signalling interface to a PSTN is either based on BICC Capability Set 2 as specified in ITU-T Recommendations 
Q.1902.1 to Q.1902.6 [30], or on ISUP (see ITU-T Recommendations Q.761 to Q.764 [4]). 

The interface towards a CS-PLMN may either be one of the interfaces mentioned in the paragraph above or a signalling 
interface based on BICC with 3GPP specific extensions, as specified for the 3GPP Nc interface in 3GPP TS 29.205 
[14], and the IM-MGW may support the 3GPP Nb interface, as specified in 3GPP TS 29.414 [25] and 3GPP TS 29.415 
[26]. If the 3GPP Nc interface is applied as signalling interface, the 3GPP Nb interface is used as user plane interface 
and the Nb UP Framing protocol is applied. 

5.2 Key characteristics of IM CN subsystem 

The IM CN subsystem uses SIP to manage IP multimedia sessions in a 3GPP environment, it also uses IPv6, as defined 
in RFC 2460 [39], as the transport mechanism for both SIP session signalling and media transport. The 3GPP profile of 
SIP defining the usage of SIP within the IM CN subsystem is specified in 3GPP TS 24.229 [9]. Example callflows are 
provided in 3GPP TS 24.228 [8]. 



6 Interworking with CS networks 

6.1 Interworking reference model 

Figure 1 details the reference model required to support interworking between the 3GPP IM CN subsystem and CS 
networks for IM basic voice calls. 
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NOTE 1 : The logical split of the signalling and bearer path between the CS network and the IIVI CN subsystem is as 

shown, however the signalling and bearer may be logically directly connected to the IIVI-MGW. 
NOTE 2: The SGW may be implemented as a stand-alone entity or it may be located in another entity either in the 

CS network or the IIVI-MGW. The implementation options are not discussed in the present document. 
NOTE 3: The IIVI-MGW may be connected via the Mb to various network entities, such as a UE (via a GTP Tunnel to 

a GGSN), an MRFP, or an application server. 
NOTE 4: A SGW function is not required for certain signalling transports, where M3UA-kSGTP-hIP is used in OS 

network and IM-MGCF. 

Figure 1 : IM CN subsystem to CS network logical interworking reference model 

6.1 .1 Interworking reference points and interfaces 

The reference points and network interfaces shown in figure 1 are as described: 

Protocol for Mg reference point: The single call control protocol applied across the Mg reference point (i.e. between 
CSCF and MGCF) will be based on the 3GPP profile of SIP as defined in accordance with 3GPP TS 24.229 [9]. 

Protocol for Mn reference point: The Mn reference point describes the interfaces between the MGCF and IM-MGW, 
and has the properties as detailed in 3GPP TS 29.332 [15]. 

Protocol for Mj reference point: The single call control protocol applied across the Mj reference point (i.e. between 
BGCF and MGCF) will be based on the 3GPP profile of SIP as defined in accordance with 3GPP TS 24.229 [9]. 

Protocol for Mb reference point: The Mb reference point is defined in accordance with 3GPP TS 23.002 [10] and is 
IPv6 based. 

6.1 .2 Interworking functional entities 



6.1.2.1 



Signalling Gateway Function (SGW) 



This component performs the call related signalling conversion to or from BICC/ISUP based MTP transport networks 
to BICC/ISUP based SCTP/IP transport networks, and forwards the converted signalling to or from the MGCF. The 
functionahty within SGW shall be in accordance with 3GPP TS 23.002 [10]. 



6.1.2.2 



Media Gateway Control Function (MGCF) 



This is the component within the IM CN subsystem, which controls the IM-MGW, and also performs SIP to BICC or 
SIP to ISUP call related signalling interworking. 

The functionality defined within MGCF shall be defined in accordance with 3GPP TS 23.002 [10]. 
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6.1 .2.3 IP Multimedia - Media Gateway Function (IM-MGW) 

This is the component within the IM CN subsystem, which provides the interface between the PS domain and the CS 
domain, and it shall support the functions as defined in accordance with 3GPP TS 23.002 [10]. 

6.2 Control plane interworking model 

Within the IM CN subsystem, the 3GPP profile of SIP is used to originate and terminate IM sessions to and from the 
UE. 

External CS networks use BICC or ISUP to originate and terminate voice calls to and from the IM CN subsystem. 

Therefore, in order to provide the required interworking to enable inter network session control, the control plane 
protocols shall be interworked within the IM CN subsystem. This function is performed within the MGCF (see 
subclause 6.1.2). 

6.3 User plane interworking model 

Within the IM CN subsystem, IPv6, and framing protocols such as RTP, are used to transport media packets to and 
from the IM CN subsystem entity like UE or MRFP. 

External legacy CS networks use circuit switched bearer channels like TDM circuits (e.g. 64 kbits PCM), ATM/AAL2 
circuit or IP bearers to carry encoded voice frames, to and from the IM CN subsystem. 

Other CN networks use ATM/A AL 1 or AAL 2 or IP as a backbone, with different framing protocols. 

Therefore, in order to provide the required interworking to enable media data exchange, the user plane protocols shall 
be translated within the IM CN subsystem. This function is performed within the IM-MGW (see subclause 6.1.2). 



7 Control plane interworking 



Signalling from CS networks to or from IM CN subsystem, where the associated supported signalling protocols are 
SS7/M3UA+ SCTP+IP and M3UA+SCTP+IP respectively, requires a level of interworking between the nodes across 
the Control Plane, i.e. the SS7 signalling function, SGW (if applicable), MGCF and SIP signalling function. This 
interworking is required in order to provide a seamless support of a user part, i.e. SIP and BICC+STCmtp or SIP and 
ISUP. 

The transport of SS7 signalling protocol messages of any protocol layer that is identified by MTP level 3, in SS7 terms, 
as a user part (MTP3-user) shall be accomplished in accordance with the protocol architecture defined in the following 
subclauses. For the present document these protocol layers include, but are not limited to. Bearer Independent Call 
Control (BICC)+STCn«p and ISDN User Part (ISUP). 

7.1 General 

The following subclauses define the signalling interworking between the Bearer Independent Call Control (BICC) or 
ISDN User Part (ISUP) protocols and Session Initiation Protocol (SIP) with its associated Session Description Protocol 
(SDP) at a MGCF. The MGCF shall act as a Type A exchange (ITU-T Recommendation Q.764 [4]) for the purposes of 
ISUP and BICC Compatibility procedures. The services that can be supported through the use of the signalling 
interworking are limited to the services that are supported by BICC or ISUP and SIP based network domains. 

BICC is the call control protocol used between Nodes in a network that incorporates separate call and bearer control. 
The BICC/ISUP capabilities or signalling information defined for national use is outside the scope of the present 
document. It does not imply interworking for national-specific capabilities is not feasible. 

The capabihties of SIP and SDP that are interworked with BICC or ISUP are defined in 3GPP TS 24.229 [9]. 

Services that are common in SIP and BICC or ISUP network domains will seamlessly interwork by using the function 
of the MGCF. The MGCF will originate and/or terminate services or capabilities that do not interwork seamlessly 
across domains according to the relevant protocol recommendation or specification. 
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Table 1 lists the services seamlessly interworked and therefore within the scope of the present document. 
Table 1 : Interworking Capabilities between BICC/ISUP and SIP profile for 3GPP 



Service 



Speech/3.1 kHz audio 

CS data Calls (optional) 

En bloc address signalling 

Overlap address signalling from the CS side towards the IMS 

Out of band transport of DTMF tones and information. (BICC only) 

Inband transport of DTMF tones and information. (BICC and ISUP) 

Direct-Dialling-ln (DDI) 

Multiple Subscriber Number (MSN) 

Calling Line Identification Presentation (CLIP) 

Calling Line Identification Restriction (CLIR) 

Connected line presentation (COLP) 

Connected line restriction (COLR) 

Carrier routeing 



7.2 Interworking between CS networks supporting ISUP and 
the IM CN subsystem 

The control plane between CS networks supporting ISUP and the IM CN subsystem supporting SIP, where the 
underlying network is SS7 and IP respectively is as shown in figure 2. 
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Figure 2: Control plane interworking between CS networks supporting ISUP 

and the IM CN subsystem 

7.2.1 Services performed by network entities in tine control plane 



7.2.1.1 



Services performed by the 887 signalling function 



The SS7 signalling function provides the capabilities to deliver or receive SS7 MTP3-User information (e.g. ISUP or 
BICC+STCmtp) across the SS7 signalling network. The functional interface of the MTP, the MTP User parts and the 
signalling network are as detailed in ITU-T Recommendations Q.701 to Q.709 [3]. 
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7.2.1.2 Services of the SGW 

The SGW shall perform the functions as described in 3GPP TS 23.002 [10]. 

In order to support the seamless operation of the MTP3-User part information between networks incorporating SS7 and 
IP (either IPv4, see RFC 791 [16], or IPv6, see RFC 2460 [39]), the SGW shall support the services of MTP as well as 
the services of the M3UA (see 3GPP TS 29.202 [20]) and SCTP (see RFC 2960 [18]). 

7.2.1 .3 Services of the MGCF 

The session handling and session control of the MGCF shall be as detailed in 3GPP TS 24.229 [9]. 

The MGCF shall provide the interaction, through the use of its interworking function, between the SS7 MTP3-User part 
information, e.g. ISUP, and SIP. The MGCF interworking function shall also provide the translation between the SS7 
MTP3-User part information and SIP, where the interworking of SIP to ISUP and BICC+STCn„p are detailed below. 

7.2.1 .4 Services of the SIP signalling function 

The SIP signalling function is a logical entity that provides the capabilities to deliver or receive multimedia session 
information across the IM CN subsystem signalling system. 

7.2.2 Signalling interactions between network entities in the control plane 
7.2.2.1 Signalling between the SS7 signalling function and MGCF 

The SGW shall enable the signalling interaction between the SS7 signalling function and the MGCF. 

7.2.2.1 .1 Signalling from MGCF to SS7 signalling function 

For signalling from the MGCF to the SS7 signalling function, the SGW shall terminate the SCTP and M3UA protocol 
layers and deliver the MTP3-User protocol messages, e.g. ISUP messages, towards the SS7 signalling function. The 
SGW transmits and receives SS7 Message Signalling Units (MSUs) to and from the SS7 signalling function over 
standard SS7 network interfaces, using MTP to provide reliable transport of the messages. 

7.2.2.1 .2 signalling from SS7 signalling function to MGCF 

For signalling from the SS7 signalling function to the MGCF, the SGW shall terminate SS7 MTP2 and MTP3 protocol 
layers and deliver MTP3-User part information messages, e.g. ISUP, towards the MGCF. In order to direct messages 
received from the SS7 MTP3 network to the appropriate IP destination, e.g. MGCF, the SGW shall perform a message 
distribution function using the information received from the MTP3-User message. Message distribution at the SGW 
shall be performed in accordance with 3GPP TS 29.202 [20]. 

7.2.2.1 .3 Services offered by SCTP and M3UA 

The SGW internal protocol mapping and transportation between BICC or ISUP messages and IP encapsulated BICC or 
ISUP messages respectively is supported by the services of the M3UA adaptation layer and the underlying SCTP layer. 
The SGW shall allow for the transfer of MTP3-User signalling messages, e.g. BICC or ISUP, to and from an MGCF, 
where the peer MTP3-User protocol exists. 

7.2.2.1 .3.1 Services offered by SCTP 

SCTP offers the ability to reliably transfer the SCTP User applications, e.g. M3UA, between the SCTP User application 
peers. The initialization procedure used for an association between two SCTP end-to-end peers, and the initialization to 
the SCTP User applications shall be performed as detailed in RCF 2960 [18]. 

7.2.2.1 .3.2 Services offered by M3UA 

When an association between two SCTP peers has been established, the use of M3UA shall provide the transport 
service in accordance with MTP (see ITU-T Recommendations Q.701 to Q.709 [3]) to the MTP3-User, e.g. ISUP. 
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7.2.2.2 Signalling between the MGCF and SIP signalling function 

Signalling between the SIP signalling function and the MGCF uses the services of IP (RFC 2460 [39]), and transport 
protocol such as TCP (RFC 793 [24]) or UDP (RFC 768 [17]) or SCTP (RFC 2960 [18]) (see 3GPP TS 24.229 [9]), and 
SIP. 

The naming and addressing concepts between the MGCF and SIP signalling function shall be detailed in accordance 
with 3GPP TS 23.228 [12]. The issues of general IP address management are discussed in 3GPP TS 23.221 [47]. 

7.2.3 SIP-ISUP protocol interworking 

When a coding of a parameter value is omitted it implies that it is not affected by the interworking and the values are 
assigned by normal protocol procedures. 

7.2.3.1 Incoming call interworking from SIP to ISUP at l-MGCF 

7.2.3.1.1 Sending of JAM 

On reception of a SIP INVITE requesting a session, the I-MGCF shall send an lAM message. The allowed sessions are 
given in subclause 7.2.3.1.2.5. 

An I-MGCF shall support both incoming INVITE requests containing SIP preconditions and lOOrel extensions in the 
SIP Supported or Require header fields, and INVITE requests not containing these extensions, unless the Note below 
applies. 

NOTE: If the I-MGCF is deployed in an IMS network that by local configuration serves no user requiring 
preconditions, the MGCF may not support incoming requests requiring preconditions. 

The I-MGCF shall interwork forked INVITE requests with different request URIs. 

If the SIP precondition extension is not included in the Supported or Require header field, the I-MGCF shall send an 
lAM immediately after the reception of the INVITE, as shown in figure 3. The I-MGCF shall set the continuity 
indicators to "Continuity check not required". 

If a Continuity Check procedure is supported in the ISUP network and SIP precondition extension are included in the 
SIP Supported or Require header field, the I-MGCF shall send the lAM immediately after the reception of the INVITE, 
as shown in figure 3. If the received SDP indicates that precondition is fulfilled the I-MGCF shall set the continuity 
indicators to "continuity check is not required". If the received SDP indicates that precondition is not fulfilled the I- 
MGCF shall set the continuity indicators to "continuity check performed on a previous circuit". The procedure in figure 
3 applies when the value of the continuity indicator is either set to "continuity check required", "continuity check 
performed on a previous circuit" or "continuity check not required". If the continuity indicator is set to "continuity 
check required" the corresponding procedures at the Mn interface described in subclause 9.2.2.3 also apply. 

I-MGCF 

INVITE ^^^, 

lAM 



Figure 3: Receipt of an INVITE request (continuity procedure supported in the ISUP network) 

If Continuity Check procedure is not supported in the ISUP network, and the SDP in the received INVITE request 
contains preconditions not met, the I-MGCF shall delay sending the lAM until the SIP preconditions are met and set the 
continuity indicators in the resulting lAM to "Continuity check not required". 
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Figure 4: Receipt of an INVITE request (continuity procedure not supported in the ISUP network) 

The I-MGCF shall reject an INVITE request for a session only containing unsupported media types by sending a status 
code 488 "Not Acceptable Here". If several media streams are contained in a single INVITE request, and if the I-MGCF 
does not support multimedia interworking according to Annex E, then the I-MGCF shall select one of the supported 
media streams, reserve the codec(s) for that media stream, and reject the other media streams and unselected codecs in 
the SDP answer, as detailed in IETF RFC 3264 [36]. If supported audio media stream(s) and supported non-audio 
media stream(s) are contained in a single INVITE request, an audio stream should be selected. 

The I-MGCF shall include a To tag in the first backward non-100 provisional response, in order to establish an early 
dialog as described in IETF RFC 3261 [19]. 

If an MGCF discovers an emergency call it shall, depending on national requirements, map that to appropriate 
indication in ISUP. 

According to IETF RFC 3261 [19] and IETF RFC 3264 [36], if an INVITE message is received without an SDP offer, 
then the I-MGCF sends an SDP offer in the first reliable non-failure message. 



7.2.3.1.2 



Coding of the lAM 



7.2.3.1.2.0 General 

The following ISDN user part parameters description can be found in ITU-T Recommendation Q.763 [4]. 

7.2.3.1.2.1 Called party number 

The E. 164 address encoded in the Request-URI shall be mapped to the called party number parameter of the lAM 

message. 
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Table 2: Coding of the called party number 



INVITE^ 


lAM^ 


Request-URI 


Called Party Number 


E.164 address 

(format -i-CC 

NDCSN) 

(e.g. as User info 

portion of a SIP 

URI with 

user=phone, or 

as tel URI) 


Address Signal: 

Analyse the information contained in received E.164 address. 

If CC is country code of the network in which the next hop terminates, then remove "-i-CC" 

and use the remaining digits to fill the Address signals. 

If CC is not the country code of the network in which the next hop terminates, then remove 

"+" and use the remaining digits to fill the Address signals. 

(NOTE 2) 


Odd/even indicator: set as required 


Nature of address indicator: 

Analyse the information contained in received E.164 address. 

If CC is country code of the network in which the next hop terminates, then set Nature of 

Address indicator to "National (significant) number". 

If CC is not the country code of the network in which the next hop terminates, then set 

Nature of Address indicator to "International number". 

(N0TE1) 


Internal Network Number Indicator: 

1 routing to internal network number not allowed 


Numbering plan Indicator: 

001 ISDN (Telephony) numbering plan (Rec. E.164) 


national operator 
option for service 
numbers: 
NonE.164 
numbers 
(as a local- 
number with a 
phone-context in 
the User Info 
portion in a SIP 

URI with 
user=phone, or 

as a local 

number with a 

phone-context in 

a tel URI) 


(NOTE 3) 


Address Signal: 

use received non E.164 number to fill the Address signals with national 
significant number. 


Odd/even indicator: set as required 


Nature of address indicator: 

"National (significant) number". (NOTE 1) 


Internal Network Number Indicator: 

1 routing to internal network number not allowed 


Numbering plan Indicator: 

001 ISDN (Telephony) numbering plan (Rec. E.164) 


(NOTE 3) 


Address Signal: 

Use received non E.164 number to fill the Address signals. 


Odd/even indicator: set as required 


Nature of address indicator: 

set Nature of Address indicator to "network-specific number" or to "reserved 

for national use". 


Internal Network Number Indicator: 

1 routing to internal network number not allowed 


Numbering plan Indicator: 

Based on operator policy other numbering plan indicators than "001 ISDN 
(Telephony) numbering plan (Rec. E.164)" can be used e.g. depending on 
phone context value. 


NOTE 1 : The usage of "nature of address indicator" value "unknown" is allowed but the mapping is not 
specified in the present specification. 

NOTE 2: If PSTN XML and ISUP Sending Terminated (ST) signal are supported as a network option, then the 
PSTN XML sendingCompletelndication, if present, is mapped to the sending terminated digit 
(hexadecimal digit F) in the address signals field of the Called Party Number parameter. 

NOTE 3: Network-specific numbers (identified by phone context according to operator policy) should be 

translated into "ISDN (Telephony) numbering plan numbers (Rec. E.164)" unless such a mapping is 
not possible and local operator"s policy requires keeping them in local format. 



7.2.3.1 .2.2 Nature of connection indicators 

bits BA Satellite indicator 

no satellite circuit in the connection 

bits DC Continuity check indicator 

continuity check not required) if the continuity check procedure is not supported in the succeeding 
network (figure 4). 
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1 continuity check required, if a continuity check shall be carried out on the succeeding circuit. 

(figure 3) 

1 continuity check performed on a previous circuit otherwise, if the continuity check procedure is 

supported in the succeeding network, but shall not be carried out on the succeeding circuit otherwise, 
(figure 3) 

Echo control device indicator 

outgoing echo control device included, for speech calls, e.g., TMR is "3.1KHz audio". 

outgoing echo control device not included, for known data calls, e.g., TMR "64 kBit/s unrestricted" 
or HLC "Facsimile Group 2/3". 

Forward call indicators 

End-to-end method indicator 

no end-to-end method available (only link-by-link method available) 

Interworking indicator 

interworking encountered 

As a network operator option, the value D = "No interworking encountered" is used if the TMR = 64 kBit/s 
unrestricted is used. 

NOTE: This avoids sending of a progress indicator with progress information 1 "Call is not end-to-end 
ISDN; further call progress information may be available in-band ", so the call will not be released for 
that reason by an ISDN terminal. 

bit E End-to-end information indicator (national use) 

no end-to-end information available 

bit F ISDN user part/BICC indicator 

ISDN user part/BICC not used all the way 

As a network operator option, the value F = 1 "ISDN user part/BICC used all the way" is used if the TMR = 64 kBit/s 
unrestricted is used. 

NOTE: This avoids sending of a progress indicator with progress information 1 "Call is not end-to-end 
ISDN; further call progress information may be available in-band ", so the call will not be released for 
that reason by an ISDN terminal. 

bits HG ISDN user part/BICC preference indicator 

if any used supplementary service requires ISUP or BICC all the way, depending on operator policy: 

ISDN user part/BICC preferred all the way, or 

1 ISDN user part/BICC required all the way; 
Otherwise: 

1 ISDN user part/BICC not required all the way 

bit I ISDN access indicator 

originating access non-ISDN 

As a network operator option, the value 1=1 "originating access ISDN" is used if the TMR = 64 kBit/s unrestricted is 
used. 

NOTE: This avoids sending of a progress indicator with progress information 1 1 "Originating access is 
non-ISDN", so the call will not be released for that reason by an ISDN terminal. 
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bits KJ SCCP method indicator 

no indication 

If the PSTN XML is supported as a network option, the Forward Call indicators derived as shown in table 02a shall take 
precedence. 

Table 02a: Mapping of PSTN XML elements to Forward call indicators parameter 



INVITE -^ 


lAM^ 


PSTN XML 


Forward call indicators parameter 


PSTN XML with Progress Indicator 


bit D Interworking Indicator 


with Progress Description value 6 


"no interworking encountered (No. 7 signalling all the way)" 


(Meaning: originating access ISDN) 


bit F ISDN User Part indicator 




1 "ISDN User Part used all the way" 




bit 1 ISDN access indicator 




1 "originating access ISDN" 


NOTE: Progress Indicator with Progress Description value "6" sliall not be included in an ATP within the lAM. | 



7.2.3.1 .2.4 Calling party's category 

See ANNEX C for the normative interworking of the CPC parameter. 

7.2.3.1. 2. 4A Originating Line Information 

The ISUP Originating Line Information parameter is defined by ANSI Standard ATIS- 10001 13 [1 17], Chapter 3. 

See Annex H for the normative interworking of the OLI parameter as a network option. 



7.2.3.1.2.5 



Transmission medium requirement 



The I-MGCF may either transcode the selected codec(s) to the codec on the PSTN side or it may attempt to interwork 
the media without transcoding. If the I-MGCF transcodes, it shall select the TMR parameter to "3.1 kHz audio". If the I- 
MGCF does not transcode, it should map the TMR, USI and Access Transport parameters from the selected codec 
according to table 2a. However, if the I-MGCF supports the PSTN XML body as a network option, and if a PSTN XML 
body is received in the INVITE request and the I-MGCF selects media encoded in any of the formats in table 2a (G.71 1, 
Clearmode or t38) among the offered media, the I-MGCF shall derive these parameters from the PSTN XML body 
instead, as detailed in table 2b. The I-MGCF should only apply the mapping in table 2b if the TMR and USI values 
derived from the selected codec according to table 2a are equivalent with the values within the first Bearer Capability 
element in the PSTN XML, and otherwise the I-MGCF should apply the mapping according to table 2a. 

The support of any of the media listed in table 2a is optional. 

If no SDP is received from the remote peer (as described in subclause 7.2.3. 1. 1), then the TMR parameter should be set 
to "3.1 kHz audio". Transcoding shall be applied as required. 
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Table 2a: Coding of TIVIR/USI/HLC from SDP: SIP to ISUP 





m= line 




b= line (NOTE 4) 


a= line 


TMR parameter 


USI parameter (optional) (NOTE 1) 


HLC IE in the 

ATP parameter 

(optional) 


<media> 


<transport> 


<fmt-list> 


<modifier>:<bandwidth- 
value> 

(NOTE 5) 


rtpmap:<dynamic-PT> 
<encoding name> 
<clock rate>[<encoding 
parameters>] 


TMR codes 


Information 

Transfer 

Capability 


User Information 
Layer 1 Protocol 
Indicator 


High Layer 

Characteristics 

Identification 


audio 


RTP/AVP 





N/A or AS: up to (64 kbit/s 
+ RTP/UDP/IP overhead) 


N/A 


"3.1 KHz audio" 






(NOTE 3) 


audio 


RTP/AVP 


Dynamic PT 


N/A or AS: up to (64 kbit/s 
+ RTP/UDP/IP overhead) 


rtpmap:<dynamic-PT> 
PCMU/8000 


"3.1 KHz audio" 






(NOTE 3) 


audio 


RTP/AVP 


8 


N/A or AS: up to (64 kbit/s-i- 
RTP/UDP/IP overhead) 


N/A 


"3.1 KHz audio" 






(NOTE 3) 


audio 


RTP/AVP 


Dynamic PT 


N/A or AS: up to (64 kbit/s 
+ RTP/UDP/IP overhead) 


rtpmap:<dynamic-PT> 
PCMA/8000 


"3.1 KHz audio" 






(NOTE 3) 


audio 


RTP/AVP 


Dynamic PT 


AS: (64 kbit/s+ 
RTP/UDP/IP overhead) 


rtpmap:<dynamic-PT> 
CLEARMODE/8000 
(NOTE 2) 


"64 kbit/s unrestricted" 
or 

"64 kbit/s preferred" 
(NOTE 7) 


"Unrestricted 
digital 

Information" 
(NOTE 6) 






image 


UdptI [73] 


t38 [73] 


N/A or AS: up to (64 kbit/s 
+ UDP/IP overhead) 


Based on ITU-T T.38 
[72] 


"3.1 KHz audio" 


"3.1 KHz audio" 




"Facsimile 
Group 2/3" 


image 


top 


t38 [73] 


N/A or AS: up to (64 kbit/s 
+ TCP/IP overhead) 


Based on ITU-T T.38 
[72] 


"3.1 KHz audio" 


"3.1 KHz audio" 




"Facsimile 
Group 2/3" 


NOTE 1 : In this table the codec G.71 1 is used only as an example. Other codecs are possible. 

NOTE 2: CLEARMODE is specified in RFC4040 [69]. 

NOTE 3: HLC is normally absent in this case. It is possible for HLC to be present with the value "Telephony", although 6.3.1/Q.939 indicates that this would normally be 

accompanied by a value of "Speech" for the Information Transfer Capability element. 
NOTE 4: The MGCP should return an b:AS bandwidth modifier with a bandwidth of 64kbit/s + RTP/UDP/IP overhead in the SDP answer to request that the peer does not send 

with a higher bandwidth. If the received b=line indicates a bandwidth greater than 64kbit/s + RTP/UDP/IP overhead, the MGCP should also accept the incoming call. 
NOTE 5: <bandwidth value> for <modifier> of AS is in units of kbit/s. 
NOTE 6: In the case where the Clearmode codec appears together with speech codecs in the same m-line, the value "Unrestricted digital inf. w/tones/ann" is applicable but is 

mapped into the US! prime parameter (see subclause 7.2.3.1.2.5a). 
NOTE 7: The value "64 k/bits preferred" should only be used if the Clearmode codec appears together with speech codecs in the same m-line and two PSTN XML Bearer 

Capability elements appear in the initial INVITE request as described in the subclause 7.2.3.1 .2.5a. 
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Table 2b: Mapping of PSTN XML elements into ISUP Parameters 



INVITE -^ 


lAM^ 1 


PSTN XML 


Value 


ISUP Parameter 


Content 


HighLayerCompatibility 




Access Transport 
Parameter 


High layer compatibility 
(N0TE1) 


LowLayerCompatibility 






Low layer compatibility 


BearerCapability (NOTE 2) 




User Service Information 




HighLayerCompatibility 




User Tele Service 


High layer compatibility 


BearerCapability 

(1 nformationlransferCapabi lity) 

(NOTE 2) 


Speech 


TMR 


Speech 


3.1 kHz audio 




3.1 kHz audio 


Unrestricted digital 
information 


64 kbit/s unrestricted 


Unrestricted digital 
information with 
tones/announcements 


64 kbit/s unrestricted 


NOTE 1 : If two high layer compatibility information elements are received, they shall be transferred in the same order 

as received in the PSTN XIVIL body in the INVITE message. 
NOTE 2: If there are two BCs present, see subclause 7.2.3.1 .2.5a. 
NOTE 3: The above mapping assumes that there is only a single BearerCapability present. 



7.2.3.1.2.5a 



Transmission medium requirement prime and USI prime (optional) 



The procedures to support UDI-TA Fallback mechanism described in the present subclause shall only apply if two 
PSTN XML Bearer Capability elements appear within the INVITE Request and the MGCF supports the PSTN XML 
body as a network option. 

When all the following conditions apply: 

The INVITE request includes SDP with one m-line with at least two formats, and with the coding of the first two 
formats appearing in table 2a; 

the TMR and USI prime values derived from the first format in the m-line according to table 2a are equivalent 
with the values within the second Bearer Capability element in the PSTN XML; 

the TMR prime and USI values derived from the second format in the m-line according to table 2a are equivalent 
with the values within the first Bearer Capability element in the PSTN XML; and. 

the I-MGCF supports forwarding fallback signalling. 

then the I-MGCF shall 

if TMR "64 kBit/s preferred" is supported at the succeeding trunk: 

- map the first XML Bearer Capability element into the "USI" within the lAM; 

map the the first PSTN XML BearerCapability (InformationTransferCapability) into the "TMR prime" within 
the lAM, applying the same mapping rules as specified for the mapping into the "TMR" in table 2b; 

map the second XML Bearer Capability element (InformationTransferCapability) into the USI prime within 
the lAM; 

- set the TMR within the lAM to "64 kBit/s preferred" ; 

- configure the IM-MGVv^; and 
store those values; 

if TMR "64 kBit/s preferred" is not supported at the succeeding trunk: 

apply the procedures as described within subclause 7.2.3.1.2.5, using the first Bearer Capability element in 
the PSTN XMLand the second format in the m-Une; 

discard the second Bearer Capability element in the PSTN XML; 
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select the second format in the m-line within the SDP answer; and 

- configure the IM-MGW. 

Otherwise (i.e. if some Bearer CapabiUty element in the PSTN XML did not match the SDP), the I-MGCF shall: 

discard the XML Bearer Capability elements; 

if the I-MGCF received at least two formats within the m-line, select one of those formats, exept for the 
CLEARMODE codec, within the SDP answer; 

apply the mapping for the selected format according to table 2a; and 

configure the IM-MGW accordingly. 
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7.2.3.1 .2.6 Calling party number 

The SIP "Privacy" header is defined within IETF RFC 3323 [40]. The SIP "P-Asserted-Identity" header is defined in 
IETF RFC 3325 [41]. 
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Table 3: Mapping of SIP From/P-Asserted-ldentity/Privacy headers to CLI parameters 



Has a "P- 


Has a "From" 


Calling Party 


Calling Party Number 


Generic 


Generic 


Asserted- 


header field 


Number 


parameter 


Number 


Number 


Identity" 


(NOTE 3) 


parameter 


APRI 


(additional 


parameter 


header field 


containing a URI 


Address signals 




calling party 


APRI 


(NOTE 2, 


that encodes an 






number) 




NOTE 5, 


E.I 64 address 






address 




NOTE 6) 


been received 






signals 




been 


(NOTE 6)? 










received? 












No 


No 


Network option to 


Network option to set 


Parameter not 


Not 






either include a 


APRI to "presentation 


included 


applicable 






network provided 


restricted" or 










E.164 number 


"presentation allowed" 










(See table 4) or 


(NOTE 4) 










omit the Address 


(See table 5) 










signals. 


As a network option the 










(NOTE 4) 


APRI "presentation 
restricted by network" 
(NOTE 7) can be used 
instead of the APRI 
"presentation restricted" 






No 


Yes 


Network Option to 


Network option to set 


Network 


APRI = 






either include a 


APRI to "presentation 


Option to 


"presentation 






network provided 


restricted" or 


either omit the 


restricted" or 






E.164 number 


"presentation allowed" 


parameter (if 


"presentation 






(See table 4) or 


(NOTE 4) 


CgPN has 


allowed" 






omit the Address 


(See table 5) 


been omitted) 


depending on 






signals. 


As a network option the 


or derive from 


SIP Privacy 






(NOTE 4) 


APRI "presentation 


the "From" 


header. 








restricted by network" 


header 


(See table 6) 








(NOTE 7) can be used 


(N0TE1) 










instead of the APRI 


(See table 6) 










"presentation restricted" 






Yes 


No 


Derive from 


APRI = "presentation 


Not included 


Not 






P-Asserted- 


restricted" or 




applicable 






Identity 


"presentation allowed" 










(See table 5) 


depending on SIP 
Privacy header. 
(See table 5) 






Yes 


Yes 


Derived from 


APRI = "presentation 


Network 


APRI = 






P-Asserted- 


restricted" or 


Option to 


"presentation 






Identity 


"presentation allowed" 


either omit the 


restricted" or 






(See table 5) 


depending on SIP 


parameter or 


"presentation 








Privacy header. 


derive from the 


allowed" 








(See table 5) 


"From" header 
(N0TE1) 
(See table 6) 


depending on 
SIP Privacy 
header, 
(see table 6) 
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Has a "P- 
Asserted- 
Identity" 
header field 
(NOTE 2, 
NOTE 5, 
NOTE 6) 

been 
received? 



Has a "From" 

header field 

(NOTE 3) 

containing a URI 

that encodes an 

E.I 64 address 

been received 

(NOTE 6)? 



Calling Party 

Number 

parameter 

Address signals 



Calling Party Number 

parameter 

APRI 



Generic 
Number 
(additional 
calling party 
number) 
address 
signals 



Generic 

Number 

parameter 

APRI 



NOTE 1 : 
NOTE 2: 

NOTE 3: 



NOTE 4: 
NOTE 5: 

NOTE 6: 



NOTE 7: 



This mapping effectively gives the equivalent of Special Arrangement to all SIP UAC with access to the 

l-MGCF. 

It is possible that the P-Asserted-ldentlty header field includes both a tel URI and a sip or sips URI. In this 

case, either the tel URI or the SIP URI with user="phone" and a specific host portion, as selected by operator 

policy, may be used. 

The "From" header may contain an "Anonymous User Identity". An "Anonymous User Identity" includes 

information that does not point to the calling party. IETF RFC 3261 recommends that the display-name 

component contain "Anonymous". That the Anonymous User Identity will take the form defined in 3GPP TS 

23.003 [74]. The Anonymous User Identity indicates that the calling party desired anonymity. The From 

header may also contain an Unavailable User Identity as defined in 3GPP TS 23.003 [74], that indicates that 

the calling party is unknown. 

A national option exists to set the APRI to "Address not available". 

3GPP TS 24.229 guarantees that the received number is an E.164 number formatted as an international 

number, with a "+" sign as prefix. 

The E.164 numbers considered within the present document are composed by a Country Code (CC), 

followed by a National Destination Code (NDC), followed by a Subscriber Number (SN). On the IMS side, the 

numbers are international public telecommunication numbers ("CC"+"NDC"+"SN") and are prefixed by a "+" 

sign. On the CS side, it is a network option to omit the CC. 

This is an ETSI specific value described within ETSI EN 300 356-1 [70]. 



Table 4: Setting of the network-provided BICC/ISUP calling party number parameter with a CLI 

(network option) 



BICC/ISUP CgPN Parameter field 


Value 


Screening Indicator 


"network provided" 


Number Incomplete Indicator 


"complete" 


Number Plan Indicator 


ISDN/Teleptiony (E. 164) 


Address Presentation Restricted Indicator 


Presentation allowed/restricted 

As a network option the APRI value "presentation restricted by network" 

(NOTE) can be used instead of the APRI value "presentation restricted" 


Nature of Address Indicator 


If next BICC/ISUP node is located in the same country set to "National 
(Significant) number" else set to "International number" 


Address signals 


If NOA is "national (significant) number" no country code should be 
included. If NOA is "international number", then the country code of the 
network-provided number should be included. 


NOTE : This is an ETSI specific value described within ETSI EN 300 356-1 [70] | 
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Table 5: Mapping of P-Asserted-ldentity and privacy hieaders to thie ISUP/BICC calling party number 

parameter 



SIP Component 


Value 


BICC/ISUP Parameter / field 


Value 


P-Asserted-ldentity 
header field (NOTE 1) 


E.164 number 


Calling Party Number 






Number incomplete indicator 


"Complete" 


Numbering Plan Indicator 


"ISDN/Telephony (E. 164)" 


Nature of Address Indicator 


If CC encoded in the URI 
is equal to the CC of the 
country where IVIGCF is 
located AND the next 
BICC/ISUP node is located 
in the same country then 
set to "national (significant) 
number" 

else set to "international 
number" 


Address Presentation Restricted 
Indicator (APRI) 


Depends on priv-value in 
Privacy header. 


Screening indicator 


Network Provided 


Addr-spec 


"CC" "NDC" "SN" from 
the URI 


Address signal 


if NOA is "national 

(significant) number" Xhen 

set to 

"NDC" + "SN" 

If NOA is "international 

number" 

Then set to 

"CC"-h"NDC"+"SN" 


Privacy header field is 
not present 




APRI 


Presentation allowed 


Privacy header field 


priv-value 


APRI 


"Address Presentation 
Restricted Indicator" 


priv-value 


"header" 


APRI 


Presentation restricted 


"user" 


APRI 


Presentation restricted 


"none" 


APRI 


Presentation allowed 


"id" 


APRI 


Presentation restricted 


NOTE 1 : It is possible that a P-Asserted -Identity header field includes both a TEL URI and a SIP or SIPS URI. 
In this case, either the TEL URI or the SIP URI with user="phone" and a specific host portion, as 
selected by operator policy, may be used. 
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7.2.3.1.2.7 



Generic number 



Table 6: Mapping of SIP from header field to BICC/ISUP generic number (additional calling party 

number) parameter (network option) 



SIP component 


Value 


BICC/ISUP parameter / field 


Value 


From header field 


name-addr or addr-spec 


Generic Number 
Number Qualifier Indicator 


"Additional Cailing Party 
number" 


from-spec 


( name-addr / addr- 
spec) 








Nature of Address Indicator 


If CC encoded in the URI is 
equal to the CC of the country 
where MGCF is located AND the 
next BICC/ISUP node is located 
in the same country then 
Set to "national (significant) 
number" 

Else set to "international 
number" 


Number incomplete indicator 


"Complete" 


Numbering Plan Indicator 


"ISDN/Telephony (E. 164)" 


APRI 


If Calling Party Number APR\ = 
"presentation restricted by 
network" (NOTE) then set GN 
APRI to "presentation allowed". 
Otherwise, use the same APRI 
setting as for Calling Party 
Number (see table 5). 


Screening indicator 


"user provided not verified" 


Addr-spec 


"CC" "NDC" + "SN" from 
the URI 


Address signal 


if NOA is "national (significant) 

number" X'nen set to 

"NDC" -1- "SN" 

If NOA is "international number" 

Then set to "CC"-i-"NDC"+"SN" 


NOTE : This an ETSI specific value described within ETSI EN 300 356-1 [70] | 



7.2.3.1.2.8 User service information 

For coding of the USI see 7.2.3.1.2.5. 



7.2.3.1.2.9 



Hop Counter (National option) 



The I-MGCF shall perform the following interworking procedure if the Hop Counter procedure is supported in the CS 
network. 

At the 1-MGCF the Max-Forwards SIP header shall be used to derive the Hop Counter parameter if applicable. Due to 
the different default values (that are based on network demands/provisions) of the SIP Max-Forwards header and the 
Hop Counter, a factor shall be used to adapt the Max Forwards to the Hop Counter at the 1-MGCF. For example, the 
following guidelines could be applied: 

1) Max-Forwards for a given message should be monotone decreasing with each successive visit to a SIP entity, 
regardless of intervening interworking, and similarly for Hop Counter. 

2) The initial and successively mapped values of Max-Forwards should be large enough to accommodate the 
maximum number of hops that may be expected of a validly routed call. 

Table 7 shows the principle of the mapping: 
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Table 7: Max forwards -- hop counter 



Max-Forwards 



X 



Hop Counter 



INTEGER part of (X /Factor) =Y 



NOTE: The Mapping of value X to Y should be done with the used (implemented) adaptation mechanism. 



The Principle of adoption could be implemented on a basis of the network provision, trust domain rules and bilateral 
agreement. 



7.2.3.1.2.10 



Progress Indicator 



If the I-MGCF supports the PSTN XML body as a network option and an INVITE containing a PSTN XML body is 
received, an available "Progresslndicator" element in the PSTN XML body shall be mapped into a Progress Indicator in 
the Access Transport Parameter of the sent lAM as shown in table 7.2.3.1.2.10.1. 

Table 7.2.3.1.2.10.1 : Contents of the Access Transport Parameter 



INVITE -^ 


lAM^ 


PSTN XML 


Access Transport Parameter 


Progress indicator 


Progress indicator (NOTE) 


NOTE: A Progresslndicator with Progress Description value 6 shall not be included into the ISUP ATP, and is 
mapped instead to Forward call indicators parameter according to table 02a. 



7.2.3.1 .2.1 1 Location Number 

Location Number is defined in section 3.30 of ITU-T Q.763 [4]. 

If the received INVITE message contains a P-Access-Network-Info header and the P-Access-Network-Info header 
contains an access-type with the value "GSTN" and a gstn-location parameter, the I-MGCF shall include an ISUP 
Location Number parameter in the outgoing lAM. 

Table 7.2.3.1 .2.1 1 .1 : Contents of the location number parameter 



INVITE -^ 


lAM^ 




Location Number parameter 


P-Access-Network-lnfo with access-type="GSTN" and 
gstn-location parameter 


value (with no quotes) of the gstn-location parameter of 
the P-Access-Network-lnfo 



£75/ 



3GPP TS 29.163 version 9.13.0 Release 9 



44 



ETSI TS 129 163 V9.13.0 (2013-04) 



Table 7.2.3.1.2.11.2: Mapping of P-Access-Network-lnfo to Location Number 



INVITE^ 


lAM^ 


P-Access-Network-lnfo 


Location Number 


access type="GSTN" 
gstn-location=value 


Address Signal: 

Copied from octet 3 to n of the binary representation of the gstn-location field 


Odd/even indicator: 

Copied from bit 8 octet 1 of the the binary representation of the gstn-location field 


Nature of address indicator: 

Copied from bit 7 to 1 of octet 1 of the the binary representation of the gstn- 
location field 


Internal Network Number Indicator: 

Copied from bit 8 of octet 2 of the the binary representation of the gstn-location 
field 


Numbering plan Indicator: 

Copied from bit 7 to 5 of octet 2 of the the binary representation of the gstn- 
location field 


Address presentation restricted indicator: 

If the SIP Privacy header field = header, APR! is set to "01 (presentation 
restricted)" otherwise APR! is copied from bit 4 and 3 of octet 2 of the binary 
representation of the gstn-location field 


Screening indicator: 

If the np parmater is present in the P-Access-Network-lnfo header field, set to "1 1 
(network provided)" otherwise set from bit 2 and 1 of octet 2 of the binary 
representation of the gstn-location field 



7.2.3.1 .2A Coding of the I AM when Number Portability is supported 

This subclause describes optional coding procedures when Number Portability is supported. 

7.2.3.1 .2A.1 Coding of the lAM when a Number Portability Routing Number is available 

ITU-T Q.769.1 [92] describes three possible addressing methods for signalling of the Called Party E.164 address and 
Number Portability Routing Number (ITU-T Q.769.1 [92] uses the terms directory number and network routing number 
respectively). The choice of these methods is based on network operator and national requirements. 

The following subclauses describe how the lAM is populated, based on these methods, when a Number Portability 
Routing Number is available in the Request URI in the form of a Tel URI "rn=" parameter. 

When the optional Number Portability Routing Number is available and supported, these procedures take precedence 
over procedures for coding of the Called Party Number described in subclause 7.2.3. 1 .2. 1 . 

If the Number Portability Database Dip Indicator is present within the Request-URI the procedures described in 
subclause 7.2.3.1.2A.2 apply. When a Number Portability Routing Number is not available, the Called Party Number 
parameter is populated as described in subclause 7.2.3.1.2.1. 
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7.2.3. 1.2A.1.1 



Separate Directory Number Addressing Metinod 



Table 7a.0a: Coding of the called party number and called directory number with Number Portability 

Separate Directory Number Addressing Method 



INVITE^ 


lAM^ 1 


Request-URI 


Called Party Number 


Called Directory Number 


Called Party E. 164 address 
(format +CC NDC SN) 
(e.g. as User info in SIP URI 
with user=phone, or as tel 
URL) plus Number Portability 
Routing Number (format +CC 
NDC SN) (e.g. as Tel URI rn= 
parameter) plus Number 
Portability Database Dip 
Indicator as defined in IETF 
RFC 4694 [93] (e.g. as Tel URI 
npdi parameter) 


Address Signal: 

Analyse the information contained in received 
Number Portability Routing Number. If the 
Number Portability Routing number contains 
an E.164 address, then remove "+CC" and use 
the remaining digits to fill the Address signal. 
Otherwise, use the digits of the Number 
Portability Routing number to fill the Address 
signal. 
(NOTE) 


Address Signal: 

Remove "+CC" from the Called 
Party E.I 64 address and use the 
remaining digits to fill the Address 
signals. 


Odd/even indicator: set as required 


Odd/even indicator: set as 

required 


Nature of address indicator: 

Set Nature of Address indicator to "Network 
routing number in national (significant) number 
fornat". "National (significant) number" and 
"Network routing number in network specific 
number format" may alternately be chosen as 
described in ITU-T 0.769.1 [92] 


Nature of address indicator: 

Set Nature of Address indicator to 
"National (significant) number". 


Internal Network Number Indicator: 

1 routing to internal network number not 
allowed 


Internal Network Number 
Indicator: 

1 routing to internal network 
number not allowed 


Numbering plan Indicator: 

001 ISDN (Telephony) numbering plan (Rec. 
E.164) 


Numbering plan Indicator: 

001 ISDN (Telephony) numbering 
plan (Rec. E.164) 


NOTE: If PSTN XML and ISUP Sending Terminated (ST) signal are supported as a network option, then the PSTN 
XML sendingCompletelndication, if present, is mapped to the sending terminated digit (hexadecimal digit F) 
in the address signals field of the Called Party Number parameter. 
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7.2.3.1.2A.1.2 



Concatenated Addressing Method 



Table 7a.0b: Coding of the called party number with Number Portability Concatenated Addressing 

Method 



INVITE^ 


lAM^ 


Request-URI 


Called Party Number 


Called Party E.164 address 

(format +CC NDC SN) 

(e.g. as User info in SIP URI with user=phone, 

or as tel URL) plus 

Number Portability Routing Number (format 

+CC NDC SN) (e.g. as Tel URI rn= parameter) 

plus 

Number Portability Database Dip Indicator as 

defined in IETF RFC 4694 [93] (e.g. as Tel URI 

npdi parameter) 


Address Signal: 

Analyse the information contained in received Number Portability 
Routing Number. If the Number Portability Routing number contains 
an E.164 address, then remove "+CC" and use the remaining digits 
to fill the Address signal. Otherwise, use the digits of the Number 
Portability Routing number to fill the Address signal. 

Remove the "+CC" from the Called Party E.164 address and 
append the remaining digits to the Address signal. 
(NOTE) 




Odd/even indicator: set as required 




Nature of address indicator: 

set Nature of Address indicator to "Network routing number 
concatenated with called directory number" or "National (significant) 
number" as described in ITU-T Q.769.1 [92] 




Internal Network Number Indicator: 

1 routing to internal network number not allowed 




Numbering plan Indicator: 

001 ISDN (Telephony) numbering plan (Rec. E.164) 


NOTE: If PSTN XIVIL and ISUP Sending Terminated (ST) signal are supported as a network option, then the PSTN 
XML sendingCompletelndication, if present, is mapped to the sending terminated digit (hexadecimal digit F) 
in the address signals field of the Called Party Number parameter. 



7.2.3.1.2A.1.3 



Separate Network Routing Number Addressing Method 



Table 7a.0c: Coding of the network routing number and called party number with Number Portability 
Separate Network Routing Number Addressing Method 



INVITE^ 


lAM^ 1 


Request-URI 


Network Routing Number 


Called Party Number 


Called Party 
E.164 address 
(format +CC NDC 
SN) 

(e.g. as User info 
in SIP URI with 
user=phone, or as 
tel URL) plus 
Number Portability 
Routing Number 
(format +CC NDC 
SN) (e.g. as Tel 
URI rn= 

parameter) plus 
Number Portability 
Database Dip 
Indicator as 
defined in IETF 
RFC 4694 [93] 
(e.g. as Tel URI 
npdi parameter) 


Address Signal: 

Analyse the information contained in received Number Portability 
Routing Number. If the Number Portability Routing number 
contains an E.164 address, then remove "+CC" and use the 
remaining digits to fill the Address signal. Otherwise, use the 
digits of the Number Portability Routing number to fill the 
Address signal. 


Address Signal: 
Remove "-i-CC" from the 
Called Party E.164 address 
and use the remaining digits 
to fill the Address signals. 
(NOTE) 


Odd/even indicator: set as required 


Odd/even indicator: set as 
required 


Nature of address indicator: 

Set Nature of Address indicator to "Network routing number in 

national (significant) number format". 

"Network routing number in network specific number format" 

may alternately be chosen as described in ITU-T 0.769.1 [92] 


Nature of address indicator: 
Set Nature of Address 
indicator to "National 
(significant) number". 


Numbering plan Indicator: 

001 ISDN (Telephony) numbering plan (Rec. E.164) 


Internal Network Number 

Indicator: 

1 routing to internal 

network number not allowed 


Numbering plan Indicator: 
001 ISDN (Telephony) 
numbering plan (Rec. E.164) 


NOTE: If PSTN XIVIL and ISUP Sending Terminated (ST) signal are supported as a network option, then the PSTN 
XIVIL sendingCompletelndication, if present, is mapped to the sending terminated digit (hexadecimal digit F) 
in the address signals field of the Called Party Number parameter. 
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7.2.3. 1.2A.2 



Number Portability Forward Information 



Network Operator or National policy may allow forward transfer of number portability status information, as described 
in ITU-T Q. 769.1 [92]. In this case, the following coding applies. 

Table 7a.0d: Coding of the number portability forward information 



INVITE^ 


lAM^ 


Request-URI 


Number Portability Forward Information 


Called Party E.164 address 

(format +CC NDC SN) 

(e.g. as User info in SIP URI with user=phone, or as 

tel URL) plus Number Portability Routing Number 

(format +CC NDC SN) (e.g. as Tel URI m= 

parameter) plus Number Portability Database Dip 

Indicator as defined in IETF RFC 4694 [93] (e.g. as 

Tel URI npdi parameter) 


If the Number Portability Database Dip Indicator is present, 
and there is no Number Portability Routing Number, set to 
"number portability query done for called number, non-ported 
called subscriber". 

If the Number Portability Database Dip Indicator is present, 
and a Number Portability Routing Number is present, set to 
"number portability query done for called number, ported 
called subscriber". 

If there is no Number Portability Database Dip Indicator, set 
to "number portability query not done for called number" 



7.2.3.1. 2B 



Coding of \he lAM for Carrier Routeing 



This subclause describes optional coding procedures for carrier-based routeing. The interworking of the CIC parameter 
is defined. 



7.2.3. 1.2B.1 



Coding of the JAM when a Carrier Identification Code (CIC) is present 



The procedures followed in subclause 7.2.3.1.2.1 apply with the following addition. 

Based on network configuration, if the tel-URI parameter in a tel-URI or the userinfo part of a SIP URI with 
user=phone in the Request-URI of an initial INVITE request, contains a "cic=" parameter, as defined in IETF RFC 
4694 [93], the I-MGCF may extract the carrier identification code from the "cic=" field for routeing the call. If the 
outgoing I AM message contains the Transit Network Selection (TNS) parameter, as defined in ITU-T Q.763 [4], based 
on network configuration the TNS may be populated using the carrier identification code from the "cic=" field. The 
format of the "cic" parameter (e.g. global-cic and local-cic) shall be compliant to IETF RFC 4694 [93]. 



7.2.3. 1.2B.2 



Void 



7.2.3.1.3 



Sending of COT 



SDP indicating 
preconditions met and/or 
active media 



I-MGCF 



COT 



Figure 5: Sending of COT 

If the lAM has already been sent, the Continuity message shall be sent indicating "continuity check successful", when 
all of the following conditions have been met: 

The requested remote preconditions (if any) in the IMS network have been met. 

The media stream previously set to inactive mode is set to active (as specified in IETF RFC 4566 [56]). 
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Local preconditions have been fulfilled. 

A possible outstanding continuity check procedure is successfully performed on the outgoing circuit. 

7.2.3.1.3A Sending of SAM 

7.2.3. 1.3A.1 General 

The procedures in the present subclause are only applicable it the I-MGCF supports the network option of overlap 
signalling, using either the in-dialog method or the multiple INVITEs method. Within one IMS only a single of those 
methods shall be used. 

After the ISUP lAM message has been sent the I-MGCF can receive additional digits. The additional digits may either, 
as a network option, be received in in-dialog SIP INFO requests (in-dialog method) as specified in subclause 
7.2.3. 1.3A.2 or in additional SIP INVITE requests (multiple INVITEs method) as specified in 7.2.3. 1.3A.3. 



I-MGCF 



SIP message 
carrying 
additional digits 



SAM 



Figure 5a: Sending of SAIV! 

7.2.3.1 .3A.2 Additional digits received in in-dialog SIP INFO requests 

If interworking of overlap signalling using the in-dialog method is supported by the I-MGCF, the ISUP lAM message 
has already been sent, but no ISUP ACM or REL message has been received, and a SIP INFO request carrying 
additional digits is received, then the I-MGCF shall generate a SAM and pass it to outgoing BICC/ISUP procedures. 
The SAM shall contain in its Subsequent Number parameter only the additional digits received in this SIP INFO 
request. 

7.2.3.1 .3A.3 Additional digits received in SIP INVITE requests 

If interworking of overlap signalling using the multiple INVITEs method is supported by the I-MGCF, the ISUP lAM 
message has already been sent, but no ISUP ACM or REL message has been received, and the I-MGCF receives an 
INVITE with the same Call-ID and From tag as a previous INVITE which was associated with a BICC/ISUP call/bearer 
control instance currently existing on the BICC/ISUP side, then: 

a) If the number of digits in the Request-URI is greater than the number of digits already received for the 
communication, the I-MGCF shall generate a SAM and pass it to outgoing BICC/ISUP procedures. The SAM 
shall contain in its Subsequent Number parameter only the additional digits received in this Request-URI 
compared with the digits already received for the communication. The I-MGCF shall reply to any earlier 
INVITE with a 484 Address Incomplete response if this has not already been done. 

b) If the number of digits in the Request-URI is equal or less than the number of digits already received for the 
communication, then the I-MGCF shall immediately send a 484 Address Incomplete response for this INVITE. 
In this case, no SAM shall be sent to BICC/ISUP procedures. 
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l-MGCF 



1. INVITE (1 



-3. INVITE (2)— ► 

—5. 484 (1) 

-6. INVITE (3)— ► 
—8. 484 (2) 



-2. lAM- 



-4. SAM- 



-7. SAM- 
-9.ACM- 



-10. 180(3)- 



Figure 5b: Receipt of subsequent INVITE for multiple INVITEs method overlap signalling 

On sending of a 484 Address Incomplete message for an INVITE transaction, the I-MGCF considers any offer/answer 
exchange initiated by the INVITE to be terminated. The new INVITE initiates a new offer/answer exchange. However, 
if resources have already been reserved and they can be reused within the new offer/answer exchange, the precondition 
signalling shall reflect the current status of the affected preconditions. 



7.2.3.1.4 



Sending of 180 ringing 



7.2.3.1.4.0 General 

The I-MGCF shall send the SIP 180 Ringing when receiving any of the following messages: 
ACM with Called party's status indicator set to subscriber free. 

I-MGCF 



180 Ringing 
P-Early-Media(l) 


ACM 
(Subscriber Free) 




^. _ 


Ring tone 







NOTE: 



The P-Early-Media header field is a included if the received INVITE contains a P-Early-IVIedia header field 
with the "supported" parameter as described in IETF RFC 5009 [89]. 

Figure 6: The receipt of ACM 



CPG with Event indicator set to alerting 
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I-MGCF 



180 Ringing 
P-Early-Media (1) 


CPG (Alerting) 








Rin^ tone 







NOTE: The P-Early-Media header field is a included if the received INVITE contains a P-Early-IVIedia header field 
with the "supported" parameter as described in IETF RFC 5009 [89]. 
Figure 7: Receipt of CPG (Alerting) 

For a speech call, if the INVITE request includes the P-Early-Media header field, the I-MGCF shall include in the SIP 
180 Ringing response a P-Early-Media header field authorizing early media, except when 

the I-MGCF has already sent a reliable provisional response (see IETF RFC 3262 [54]) including a P-Early- 
Media header, as defined in IETF RFC 5009 [89], and 

the most recently sent P-Early-Media header field authorized early media. 

NOTE: If the I-MGCF signals the P-Early-Media header field authorizing early media, then the IMS can expect 
tones or announcements to the calling party to flow from the CS network via an MGW controlled by the 
I-MGCF. In particular, once the I-MGCF sends the 180 Ringing response, ringback is expected in media 
from the CS network. 

As a network option, an I-MGCF may generate a Call-Info header field, or an Alert-Info header field according to rules 
and procedures of IETF RFC 3261 [19] to provide media instead of the in-band media received from the PSTN. 



7.2.3.1.4.0a 



PSTN XML body 



The procedures in the present subclause apply only if the I-MGCF supports the PSTN XML body as a network option. 
The I-MGCF shall map the Access Transport parameter received in the CPG or ACM into PSTN XML elements as 
shown in table 7a.0f and include this PSTN XML body in the 180 Ringing. 

Table 7a.0f : Mapping of ATP ISUP Parameter into PSTN XML elements 



^18x 


^CPG or ACM | 


PSTN XML 


ISUP Parameter 


Content 


Progresslndicator 


Access Transport Parameter 


Progress indicator 


HighLayerCompatibility (NOTE 2) 


High layer compatibility 


LowLayerCompatibility (NOTE 2) 


Low layer compatibility 


Bearer Capability (NOTE 1 , NOTE 2) 


Bearer Capability 


BearerCapability (NOTE 1 , NOTE 2) 


Transmission medium used 
parameter (NOTE 1) 




NOTE 1 : see subclause 7.2.3.1 .4.1 Transmission IVIedium Used parameter (TIVIU) 

NOTE 2: The I-MGCF shall only provide this IE if it interworks media encoded in any of the formats in table 2a 

(G.71 1 , Clearmode, or 138) without transcoding. If both TMU and a BC in the ATP have been received, the 

BC in the ATP shall be mapped. 



The I-MGCF shall map a possibly available "Progress indicator" element in the ATP parameter within the ACM or 
CPG into a Progress Indicator in the PSTN XML body of the 180 Ringing. In addition, the I-MGCF shall map the 
Backward call indicators parameter and the Optional backward call indicators parameter (if present) within the ACM or 
CPG into other Progresslndicator(s) in the PSTN XML body of the 180 Ringing as shown in table 7a.0g. 

NOTE: The order of Progresslndicators within the same PSTN XML body is irrelevant. 
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Table 7a.0g: Mapping of ISUP BCI and optional BCI parameters into PSTN XIUIL Progresslndicator 



<- 180 Ringing 


<-ACM or CPG 


PSTN XML body with Progresslndicator with "Progress 
Description" value No (Value of PI) (NOTE) 


Backward call indicators parameter 
Optional backward call indicators parameter 


No. 1 

("Call is not end-to-end ISDN: further call progress 

information may be available in-band") 


Backward call indicators parameter 
ISDN User Part indicator 

"ISDN User Part not used all the way" 


No. 2 

("Destination address is non-ISDN") 


Backward call indicators parameter 
ISDN User Part indicator 

1 "ISDN User Part used all the way" 
ISDN access indicator 

"Terminating access non-ISDN" 


No. 7 

("Terminating access ISDN") 


Backward call indicators parameter 
ISDN User Part indicator 

1 "ISDN User Part used all the way" 
ISDN access indicator 

1 "Terminating access ISDN" 


No. 8 

("In-band information or an appropriate pattern is now 

available") 


Optional backward call indicators parameter 
In-band information indicator 
"in-band information or an appropriate pattern is 
now available" 


NOTE: The Progresslndicator "Coding Standard" parameter shall be set to "00 (ITU-T standardized coding)". The 
default value for the Progress Indicator "Location" parameter is "001 1 (Transit Network)". 



7.2.3.1.4.0b 



Fallback by l-MGCF 



If the I-MGCF supports the PSTN XML body as a network option and the I-MGCF received two PSTN XML Bearer 
Capability elements within the INVITE Request, but the succeeding trunk does not support TMR "64 kBit/s preferred" 
(as described in subclause 7.2.3.1.2.5a), and if no corresponding elements were received in the Access Transport 
Parameter (see table 7a. Of), then the I-MGCF shall create a PSTN XML body containing the following elements, and 
include it in the 18x Response : 

a BearerCapability element, which shall becopied from the first BearerCapability element received in the PSTN 
XML in the INVITE; 

if two HighLayerCompatibility elements were present in the PSTN XML body in the INVITE, then a 
HighLayerCompatibility element, which shall be copied from the first HighLayerCompatibility element received 
in the PSTN XML in the INVITE; and 

a Progresslndicator element with "Progress Description" value 5 ("Interworking has occurred and has resulted in 
a telecommunication service change"), "Coding Standard" value "00 (ITU-T standardized coding)", and default 
value "0011 (Transit Network)" for the "Location" parameter. 



7.2.3.1.4.1 



Fallback in a succeeding network: Transmission Medium Used parameter (TMU) 
received 



The procedures in the present subclause apply only if the I-MGCF supports the PSTN XML body as a network option 
and receives a Transmission Medium Used parameter (TMU). 

NOTE: The I-MGCF will only receive a TMU parameter if it has applied the Fallback related procedures in 
subclause 7.2.3.1.2.5a, including both a TMR and TMR Prime in the lAM, and fallback to the bearer 
capability identified in TMR Prime and USI occurred in a succeeding network. 

If the I-MGCF receives a Transmission Medium Used parameter (TMU) , the I-MGCF shall: 

If an BC is not available in the ATP in the Address Complete Message (ACM) or Call Progress Message (CPG), 
map the TMU value (Speech or 3.1 kHz audio) to the PSTN XML BearerCapability; 

If an BC is available in the ATP in the Address Complete Message (ACM) or Call Progress Message (CPG), 
include the received BC value in the PSTN XML BearerCapability; 

configure the IM-MGW to use the second format in the m-line in the SDP that has been received in the INVITE 
as codec at the IMS termination; and 



£75/ 



3GPP TS 29.163 version 9.13.0 Release 9 



52 



ETSI TS 129 163 V9.13.0 (2013-04) 



send SDP selecting the second format in the m-line of the SDP that has been received in the INVITE as soon as 
allowed according to SIP rules. 

Table 7.2.3.1.4.1.1: Sending of BC fallback indication 



<- 180 Ringing or 183 Session Progress 


<-ACM/CPG 


PSTN XML BearerCapability = "Speech" 


TMU "Speech" 
ATP No BC 


PSTN XML BearerCapability = "3.1 kHz audio" 


TMU "3.1 kHz audio" 
ATP No BC 


PSTN XML BearerCapability received in the ATP 
("speech" or "3.1 kHz audio") 


TMU "Speech" or "3.1 kHz audio" 
ATP BC ("speech" or "3.1 kHz audio") 



7.2.3.1. 4A 



Sending of 183 Session Progress for early media scenarios 



If SIP preconditions are used, the first 183 Session Progress will be sent after the reception of the INVITE request, 
before any ISUP message has been received from the CS network. The I-MGCF shall not include the P-Early-Media 
header field in any SIP message before it receives an ISUP ACM. 

For a speech call upon receipt of one of the following messages and if the I-MGCF has received the P-Early-Media 
header field in the INVITE request, and has not already sent a provisional response including a P-Early-Media header 
field with parameters indicating authorization of early media, then the I-MGCF shall send the 183 Session Progress 
response with a P-Early-Media header field authorizing early media: 

ACM with the value of the called party"s status indicator "no indication" and one of the options described in 
table 7.2.3. 1.4A.1. If the I-MGCF supports the PSTN XML body as a network option, the I-MGCF shall map 
parameters within the ACM into the PSTN XML body within the 183 as indicated in table 7.2.3.1.4A.1. Based 
on local configuration, the I-MGCF may also send a 183 Session Progress response with a P-Early-Media header 
field authorizing early media if it receives an ACM with other parameters than described in table 7.2.3.1.4A.1. 

I-MGCF 



183 Progress 

P THarl\7 IVT f=*rl ill 


ACM 

(No indication) 

- 






^ ^__^__^__^__ 


appropriate announcement 







Figure 7c: Receipt of ACM "No indication" 
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Table 7.2.3. 1.4A.1 : ACM Parameters that trigger the 183 Session Progress response 



<-183 Session Progress 


<-ACM 


P-Early-Media header field authorizing early media, if not 
already sent 

PSTN XML with Progresslndicator with "Progress 
Description" value No. 8 

("In-band information or appropriate pattern is now 
available") (NOTE) 


Optional backward call indicators parameter 

In-band information indicator 
1 "In-band info or an appropriate pattern is now 
available" 


PSTN XIVIL with Progresslndicator with "Progress 
Description" value No. 1 

("Call is not end-to-end ISDN: further call progress 
information may be available in-band") (NOTE) 


Backward call indicators parameter 

ISDN User Part indicator 
"ISDN User Part not used all the way" 


PSTN XML with Progresslndicator with "Progress 
Description" value No. 2 ("Destination address is non- 
ISDN") (NOTE) 


Backward call indicators parameter 

ISDN User Part indicator 

"ISDN User Part used all the way" 

ISDN access indicator 

"Terminating access non-ISDN" 


PSTN XML with Progresslndicator with "Progress 
Description" value No. 7 
("Terminating access ISDN") (NOTE) 


Backward call indicators parameter 
ISDN User Part indicator 

1 "ISDN User Part used all the way" 

ISDN access indicator 

1 "Terminating access ISDN" 


NOTE: The Progresslndicator "Coding Standard" parameter shall be set to "00 (ITU-T standardized coding)". The 
default value for the Progresslndicator "Location" parameter is "001 1 (Transit Network)". 



NOTE 1: As a network option the I-MGCF can also map ACM into 183 in other cases than those described in table 

7.2.3. 1.4A.1. 

CPG message, when: 

1. Event indicator is set to "in-band information or an appropriate pattern is now available", or 

2. Event indicator is set to "Progress" and one of the options described in table 7.2.3. 1 .4A.2. 



I-MGCF 



183 Progress 
P-Early-Media 






CPG 

(in-band information available) 



a]>pro2riate aniiojincment 



Figure 7d: Receipt of CPG (in-band information available) 
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Table 7.2.3. 1.4A.2: CPG Parameters that trigger the 183 Session Progress response 



<-183 Session Progress 


<-CPG 


P-Early-Media header field authorizing early media, 
if not already sent 

PSTN XML with Progresslndicator with "Progress 
Description" value No. 8 

("In-band information or appropriate pattern is now 
available") (NOTE 3) 


Event indicator 

000 0010 (progress) 

Optional backward call indicators parameter 

In-band information indicator 

1 "In-band info or an appropriate pattern is now 

available" 


PSTN XIVIL with Progresslndicator with "Progress 
Description" value No. 1 
(Call is not end-to-end ISDN: further progress 
information may be available in-band") (NOTE 3) 


Event indicator 

000 0010 (progress) 

Baclcward call indicators parameter 

ISDN User Part indicator 

"ISDN User Part not used all the way" 


PSTN XIVIL with Progresslndicator with "Progress 
Description" value No. 2 ("Destination address is 
non-ISDN") (NOTE 3) 


Baclcward call indicators parameter 

ISDN User Part indicator 

"ISDN User Part used all the way" 

ISDN access indicator 

"Terminating access non-ISDN" 


PSTN XIVIL with Progresslndicator with "Progress 
Description" value No. 7 
("Terminating access ISDN") (NOTE 3) 


Bacl^ward call indicators parameter 

ISDN User Part indicator 

"ISDN User Part used all the way" 

ISDN access indicator 

1 "Terminating access ISDN" 


NOTE 1 : The mapping of the contents in the CPG message is only relevant if the information received in the 

message is different compared to earlier received information, e.g., in the ACM message or a CPG 

message received prior to this message. 
NOTE 2: 183 Session Progress message including a P-Early-Media header authorizing early media may only be 

sent for a speech call. 
NOTE 3: The Progresslndicator "Coding Standard" parameter shall be set to "00 (ITU-T standardized coding)". The 

default value for the Progresslndicator "Location" parameter is "001 1 (Transit Network)". 



NOTE 2: As a network option the I-MGCF can also map CPG into 183 in other cases than those described in table 
7.2.3. 1.4A.1. 

If the I-MGCF supports the PSTN XML body as a network option, the I-MGCF shall map the Access Transport 
Parameter received in the CPG or ACM into PSTN XML elements as shown in table 7a.0f and include this PSTN XML 
body in the 183 Session Progress. The I-MGCF shall include both a Progresslndicator mapped from possibly received 
Progress indicator element in the Access Transport Parameter and Progresslndicators derived according to table 
7.2.3. 1.4A.1 or table 7.2.3. 1.4A.2 in the PSTN XML body. 

NOTE 3: The order of Progresslndicators within the same PSTN XML body is irrelevant. 

If the I-MGCF has applied UDI-TA fallback related procedures in subclause 7.2.3. 1.2.5a, the I-MGCF shall also apply 
the procedures in subclauses 7.2.3.1.4.0b and 7.2.3.1.4.1, including the PSTN XML body in the 183 Session Progress. 

As a network option, an I-MGCF may generate a Call-Info header field, or an Alert-Info header field according to rules 
and procedures of IETF RFC 3261 [19] to provide media instead of the in-band media received from the PSTN. 

If the ACM or CPG contains an ISUP Cause, the MGCF may add a Reason header field containing the received Cause 
Value to the SIP 183 Session Progress provisional response as a network option. The mapping of the Cause Indicators 
parameter to the Reason header as shown in table 9a shall be applied. IETF RFC 6432 [1 15] describes the use of the 
Reason header field in responses. The Reason header field itself is described in IETF RFC 3326 [116]. 

7.2.3.1 .4B Sending of 1 81 Call is being forwarded 

The I-MGCF shall send the SIP 181 Call is being forwarded when receiving any of the following messages: 
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ACM with call diversion information not indicating that presentation is not allowed and optional backward call 
indicators indicate that in-band information is available. 

I-MGCF 
181 Call is being 



forwarded 
P-Early-Media (1) 

-^ 



ACM( call diver- 
sion information) 

N 



Audio 



NOTE 1 : The P-Early-Media header field is a included if the received INVITE contains a P-Early-IVIedia header field 
with the "supported" parameter as described in IETF RFC 5009 [89]. 

Figure 7c: The receipt of ACIVI (call diversion information) 

CPG with call diversion information not indicating that presentation is not allowed and optional backward call 
indicators indicate that in-band information is available. 

I-MGCF 

181 Call is being 



forwarded 
P-Early-Media (1) 


CPG(Call diversion 
information) 






^ 


Audio 



NOTE 1 : The P-Early-Media header field is a included if the received INVITE contains a P-Early-Media header field 
with the "supported" parameter as described in IETF RFC 5009 [89]. 

Figure 7d: Receipt of CPG (Call diversion information) 

For a speech call, if the INVITE request includes the P-Early-Media header field, the I-MGCF shall include in the SIP 
181 Call is being forwarded response a P-Early-Media header field authorizing early media, except when 

the I-MGCF has already sent a reliable provisional response including a P-Early-Media header field, as defined 
in IETF RFC 5009 [89], or a 180 Ringing response; and 

the most recently sent P-Early-Media header field authorized early media. 

NOTE: If the I-MGCF signals the P-Early-Media header field authorizing early media, then the IMS can expect 
tones or announcements to the calling party to flow from the CS network via an MGW controlled by the 
I-MGCF. 



7.2.3.1. 4C 



Sending of 183 Session Progress for overlap signalling using the in-dialog 
method 



If the I-MGCF supports the network option of overlap signalling using the in-dialog method, and the SIP INVITE 
request contained an indication that the lOOrel extension is supported or required, the I-MGCF shall send a reliable 183 
(Session Progress) response immediately after the reception of an INVITE request. 

NOTE: If the INVITE request does not contain an indication that the lOOrel extension is supported or required, it 
is assumed that overlap is not used, and that no further digits will be received. 

7.2.3.1 .4D Sending of 1 83 Session Progress to carry ISUP Cause 

If the I-MGCF receives an ACM or CPG message containing an ISUP Cause, and if the I-MGCF does not send any SIP 
provisional response due to interworking procedures described in subclauses 7.2.3.1.4A, for the ACM or CPG message. 
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the I-MGCF may send a SIP 183 Session Progress with a Reason header field containing the received Cause Value as a 
network option. The mapping of the Cause Indicators parameter to the Reason header as shown in table 9a shall be 
applied. IETF RFC 6432 [115] describes the use of the Reason header field in responses. The Reason header field itself 
is described in IETF RFC 3326 [1 16]. 

I-MGCF 



183 Session Progress 
(Reason(Cause=xxx)) 


ACM or CPG 

(Cause=xxx) 











Figure 7.2.3. 1.4D.1 : The receipt of ACIUI or CPG witli ISUP Cause 

7.2.3.1 .5 Sending of the 200 OK (INVITE) 

The following cases are possible trigger conditions for sending the 200 OK (INVITE): 
The reception of the ANM. 

I-MGCF 



200 OK (INVITE) 


^ 


ANM 


^ 


^ 




^ 





Figure 8: Receipt of ANIV! 

The reception of the CON message. 

I-MGCF 



200 OK (INVITE) 


^ 


CON 


^ 


^ 




^ 





Figure 9: Receipt of CON 

If the I-MGCF supports the PSTN XML body as a network option, the I-MGCF shall map the Access Transport 
Parameter received in the ANM or CON into PSTN XML elements as shown in table 7.2.3.1.5.1 and include this PSTN 
XML body in the 200 OK (INVITE). 

On receipt of an ANM/CON message containing the ATP including the Bearer Capability set to "unrestricted digital 
information with tones/announcement" without TMU parameter the 200 OK message shall contain the PSTN XML 
Bearer Capability "unrestricted digital information with tones/announcement". 

If the I-MGCF supports the PSTN XML body as a network option, the I-MGCF shall map an available BCI element in 
the ANM or CON into a Progresslndicator in the PSTN XML body as shown in table 7.2.3.1.5.2; the I-MGCF shall 
include both a Progresslndicator mapped from possibly received Progress indicator element in the Access Transport 
Parameter and Progresslndicators derived according to table 7.2.3.1.5.2 in the PSTN XML. 

NOTE 1 : The order of Progresslndicators within the same PSTN XML body is irrelevant. 
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Table 7.2.3.1.5.1 : Mapping of ISUP ATP Parameter into PSTN XIUIL elements 



^200 OK 


^ANM or CON | 


PSTN XML 


ISUP Parameter 


Content 


Progresslndicator 


Access Transport Parameter 


Progress Indicator 


HighLayerCompatibility (NOTE 2) 


High layer compatibility 


LowLayerCompatibility (NOTE 2) 


Low layer compatibility 


BearerCapability (NOTE 1 , NOTE 2) 


Bearer Capability 


BearerCapability (NOTE 1 , NOTE 2) 


Transmission medium used 
parameter (NOTE 1) 




NOTE 1 : see subclause 7.2.3.1 .4.1 Transmission IVIedium Used parameter (TIVIU) 

NOTE 2: The l-MGCF shall only provide this IE if it interworks media encoded in any of the formats in table 2a 

(G.71 1 , Clearmode, or 138) without transcoding. If both TMU and a BC in the ATP have been received, the 

BC in the ATP shall be mapped. 



Table 7.2.3.1.5.2: IVIapping of ISUP BCI and optional BCI parameters into PSTN XIVIL 

Progresslndicator 



<r- 200 OK 


<-ANM or CON 


PSTN XML body with Progresslndicator with 
"Progress Description" value No (Value of PI) (NOTE) 


Content 

Backward call indicators parameter 

Optional backward call indicators parameter 


No. 1 

("Call is not end-to-end ISDN: further call progress 

information may be available in-band") 


Backward call indicators parameter 
ISDN User Part indicator 

"ISDN User Part not used all the way" 


No. 2 

("Destination address is non-ISDN") 


Backward call indicators parameter 
ISDN User Part indicator 

1 "ISDN User Part used all the way" 
ISDN access indicator 

"Terminating access non-ISDN" 


No. 7 

("Terminating access ISDN") 


Backward call indicators parameter 
ISDN User Part indicator 

1 "ISDN User Part used all the way" 
ISDN access indicator 

1 "Terminating access ISDN" 


No. 8 

("In-band Information or an appropriate pattern is now 

available") 


Optional backward call indicators parameter 
In-band information indicator 

1 "in-band information or an appropriate 
pattern is now available" 


NOTE: The Progress Indicator "Coding Standard" parameter shall be set to "00 (ITU-T standardized coding)". The 
default value for the Progresslndicator "Location" parameter is "001 1 (Transit Network)". 



If the I-MGCF supports the PSTN XML body and receives a Transmission Medium Used (TMU) parameter, 

NOTE 2: The I-MGCF will only receive a TMU parameter if it has applied the Fallback related procedures in 

subclause 7.2.3.1.2.5a, including both a USI and TMR Prime parameter in the lAM, and fallback to the 
bearer capability identified in USI and TMR Prime occurred at the terminating side. 

then the I-MGCF shall: 

- if a BC is not available in the ATP in the ANM or CON, map the TMU value (Speech or 3. 1 kHz audio) to the 
PSTN XML BearerCapabiHty element; 

- if a BC is available in the ATP in the ANM or CON, include the received BC in the PSTN XML 
BearerCapability element; 

configure the IM-MGW to use the second format in the m-line in the SDP that has been received in the INVITE 
as codec at the IMS termination; and 

send SDP selecting the second format in the m-line of the SDP that has been received in the INVITE as soon as 
allowed according to SIP rules. 
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If the I-MGCF supports the PSTN XML body, has applied the Fallback related procedures in subclause 7.2.3. 1 .2.5a, 
including both a TMR and TMR Prime in the lAM, and did not receive TMU in the ANM, CON, or any previous ISUP 
message, 

NOTE 3: Fallback to the bearer capability identified in TMR did not occurre at the terminating side. 

then the I-MGCF shall: 

configure the IM-MGW to use the first format in the m-line in the SDP offer that has been received in the 
INVITE as codec at the IMS termination; and 

send SDP selecting the first format in the m-line in the SDP offer at the first possibility according to SIP rules. 

7.2.3.1 .6 Sending of the Release message (REL) 

The following are possible triggers for sending the Release message: 
Receipt of the BYE method 



I-MGCF 



BYE 



REL 



Figure 10: Receipt of thie Bye methiod 

Receipt of the CANCEL method 



I-MGCF 



CANCEL 



REL 



Figure 1 1 : Receipt of Cancel method 

Additional triggers are contained in table 10. 



7.2.3.1.7 



Coding of the REL 



If the Reason header field with Q.850 Cause Value is included in the BYE or CANCEL request, then the Cause Value 
shall be mapped to the ISUP Cause Value field in the ISUP REL. The mapping of the Reason header to the Cause 
Indicators parameter is shown in table 8a. Table 8 shows the coding of the Cause Value in the REL if it is not available 
from the Reason header field. In both cases, the Location Field shall be set to "network beyond interworking point" . 

Table 8: Coding of REL 



SIP Message -^ 


REL^ 


Request 


cause indicators parameter 


BYE 


Cause value No. 16 (normal clearing) 


CANCEL 


Cause value No. 16 (normal clearing) 
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Table 8a: Mapping of SIP Reason header fields 
into Cause Indicators parameter 



Component of SIP 
Reason header field 


Component value 


BICC/ISUP Parameter field 


Value 


Protocol 


"Q.850' 


Cause Indicators parameter 


- 


protocol-cause 


"cause = XX" (NOTE 1) 


Cause Value 


"XX' (NOTE 1 ) 


— 


— 


Location 


"network beyond 
interworking point" 


NOTE 1 : "XX" is the Cause Value as defined in ITU-T Recommendation Q.850 [38]. | 



Editor"s Note: The mapping of reason headers towards the ISDN may be misused due to possible user creation of 
the reason header since there is no screening in IMS. 

If the I-MGCF supports this PSTN XML body as a network option and the I-MGCF interworks media encoded in any 
of the formats in table 2a (G.7 1 1 , Clearmode or t38) without transcoding, and if a PSTN XML body is received in the 
BYE or CANCEL request, the I-MGCF shall derive the Access Transport Parameter in the REL message from the 
PSTN XML body as shown in table 8b. 

Table 8b: Mapping of PSTN XML elements into ISUP Parameters 



BYE or CANCEL ^ 


REL^ 1 


PSTN XML 


ISUP Parameter 


Content 


HighLayerCompatibility 


Access Transport Parameter 


High layer compatibility 


LowLayerCompatibility 


Low layer compatibility 



7.2.3.1.8 



Receipt of the Release Message 



If the REL message is received and a final response (i.e. 200 OK (INVITE)) has already been sent, the I-MGCF shall 
send a BYE message. 

NOTE: According to SIP procedures, in the case that the REL message is received and a final response (e.g. 200 
OK (INVITE)) has already been sent (but no ACK request has been received) on the incoming side of the 
I-MGCF then the I-MGCF does not send a 487 Request terminated response and instead waits until the 
ACK request is received before sending a BYE message. 

If the REL message is received and the final response (i.e. 200 OK (INVITE)) has not already been sent, the I-MGCF 
shall send a Status-Code 4xx (Client Error), 5xx (Server Error) or 6xx (Global Failure) response. The Status code to be 
sent is determined by examining the Cause value received in the REL message. Table 9 specifies the mapping of the 
cause values, as defined in ITU-T Recommendation Q.850 [38], to SIP response status codes. Cause values not 
appearing in the table shall have the same mapping as the appropriate class defaults according to ITU-T 
Recommendation Q.850 [38]. 
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Table 9: Receipt of the Release message (REL) 



<-SIP Message 


<-REL 


Status code 


Cause indicators parameter 


404 Not Found 


Cause value No 1 (Unallocated (unassigned) number) 


604 Does not exist anywhere 


Cause value No 2 (No route to specified transit network) 


604 Does not exist anywhere 


Cause value No 3 (No route to destination) 


500 Server Internal error 


Cause value No 4 (Send special information tone) 


404 Not Found 


Cause value No 5 (IVIisdialled trunk prefix) 


486 Busy Here 


Cause value No 1 7 (User busy) 


480 Temporarily unavailable 


Cause value No 18 (No user responding) 


480 Temporarily unavailable 


Cause value No 19 (No answer from user (user alerted)) 


480 Temporarily unavailable 


Cause value No 20 (Subscriber absent) 


603 Decline IF location field is set to user 
ELSE 403 Forbidden 


Cause value No 21 (Call rejected) 


410 Gone 


Cause value No 22 (Number changed) 


410 Gone 


Cause value No 23 (Redirection to new destination) 


433 Anonymity Disallowed (NOTE 1) 


Cause value No 24 (Call rejected due to ACR supplementary service) 


483 Too IVIany Hops 


Cause value No 25 (Exchange routing error) 


480 Temporarily unavailable 


Cause value No 26 (Non-selected user clearing) 


502 Bad Gateway 


Cause value No 27 (Destination out of order) 


484 Address Incomplete 


Cause value No 28 (Invalid number format (address incomplete)) 


501 (Not Implemented) 


Cause value No 29 (Facility rejected) 


480 Temporarily unavailable 


Cause value No 31 (Normal, unspecified) 
(class default) (NOTE 2) 


486 Busy here if Diagnostics indicator 
includes the (COBS indicator = COBS 

possible) 
else 503 Service Unavailable (NOTE 3) 


Cause value No 34 (No circuit/channel available) 


500 Server Internal error 


Cause value No 38 (Network out of order) 


503 Service Unavailable (NOTE 3) 


Cause value No 41 (Temporary failure) 


503 Service Unavailable (NOTE 3) 


Cause value No 42 (Switching equipment congestion) 


500 Server Internal error 


Cause value No 43 (Access information discarded) 


503 Service Unavailable (NOTE 3) 


Cause value No 44 (Requested channel not available) 


500 Server Internal error 


Cause value No 46 (Precedence call blocked) 


503 Service Unavailable (NOTE 3) 


Cause value No 47 (Resource unavailable, unspecified) 
(class default) 


488 Not acceptable here 


Cause value No 50 (Requested facility not subscribed) 


603 Decline 


Cause value No 55 (Incoming class barred within Closed User Group 

(CUG)) 


603 Decline 


Cause value No 57 (Bearer capability not authorised) 


503 Service Unavailable (NOTE 3) 


Cause value No 58 (Bearer capability not presently available) 


501 (Not Implemented) 


Cause value No 63 (Service option not available, unspecified) 
(class default) 


500 Server Internal error 


Cause value No 65 (Bearer capability not implemented) 


501 Not Implemented 


Cause value No 69 (Requested facility not implemented) 


501 Not Implemented 


Cause value No 70 (Only restricted digital information capability is 

available) 


501 Not Implemented 


Cause value No 79 (Service or option not implemented, unspecified) 

(class default) 


403 Forbidden 


Cause value No 87 (User not member of Closed User Group (CUG)) 


606 Not Acceptable 


Cause value No 88 (Incompatible destination) 


403 Forbidden 


Cause value No 90 (Non existing Closed User Group (CUG)) 


500 Server Internal error 


Cause value No 91 (Invalid transit network selection) 


500 Server Internal error 


Cause value No 95 (Invalid message, unspecified) 
(class default) 


501 Not Implemented 


Cause value No 97 (IVIessage type non-existent or not implemented) 


501 Not Implemented 


Cause value No 98 (Message not compatible with call state or message 
type non-existent or not implemented) 


501 Not Implemented 


Cause value No 99 (Information element/parameter non-existent or not 

implemented) 


504 Server timeout 


Cause value No 102 (Recovery on timer expiry) 


501 Not Implemented 


Cause value No 103 (Parameter non-existent or not implemented, 

passed on) 
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<-SIP Message 


<-REL 


Status code 


Cause indicators parameter 


501 Not Implemented 


Cause value No 1 10 (Message with unrecognised parameter, 
discarded) 


400 Bad Request 


Cause value No 1 1 1 (Protocol error, unspecified) 
(class default) 


500 Server Internal error 


Cause value No127 (Interworking, unspecified) 
(class default) 


NOTE 1 : Anonymity Disallowed, IETF RFC 5079 [77] refers 
NOTE 2: Class and class 1 have the same default value. 
NOTE 3: No Retry-After header field shall be included. 



A Reason header field containing the received (Q.850) Cause Value of the REL shall be added to the SIP final response 
or BYE request sent as a result of this subclause. The mapping of the Cause Indicators parameter to the Reason header 
is shown in table 9a. IETF RFC 6432 [115] describes the use of the Reason header field in responses. The Reason 
header field itself is described in IETF RFC 3326 [116]. 

Table 9a: Mapping of Cause Indicators parameter into SIP Reason header fields 



Cause indicators 
parameter field 


Value of parameter 
field 


component of SIP 
Reason header field 


component value 


- 


- 


protocol 


"Q.850' 


Cause Value 


"XX" (NOTE 1) 


protocol-cause 


"cause = XX' (NOTE 1) 






reason-text 


Should be filled with the 
definition text as stated in 
ITU-T Recommendation 
O.850 [38]. 
(NOTE 2) 


NOTE 1 : "XX" is the Cause Value as defined in ITU-T Recommendation Q.850 [38]. 

NOTE 2: Due to the fact that the Cause Indicators parameter does not include the definition text as defined in 
table 1 /Q.850 [38], this is based on provisioning in the l-MGCF. 



As a network option, an I-MGCF may generate an Error-Info header field according to rules and procedures of 
IETF RFC 3261 [19] to provide media instead of the in-band media received from the PSTN. 

If the I-MGCF supports the PSTN XML body as a network option, the I-MGCF shall map the Access Transport 
Parameter received in the REL into PSTN XML elements as shown in table 9aa and include this PSTN XML body in 
the SIP final response or BYE. 

Table 9aa: Mapping of ISUP Parameters into PSTN XML elements 



^4xx,5xx,6xx or BYE 


^REL 1 


PSTN XML 


ISUP Parameter 


Content 


Progresslndicator 


Access Transport Parameter 


Progress indicator 


HighLayerCompatibility (NOTE) 


High layer compatibility 


LowLayerCompatibility (NOTE) 


Low layer compatibility 


NOTE: The I-MGCF shall only provide this IE if it interworks media encoded in any of the formats in table 2a 
(G.71 1 , Clearmode, or 138) without transcoding. 



7.2.3.1.9 



Receipt of RSC, GRS or CGB (H/W oriented) 



Upon receipt of a RSC, GRS or CGB (H/W oriented) message the following applies independently for each affected 
circuit: 

NOTE: For the RSC message, the circuit identified by the CIC is affected. 

For the GRS message, the affected circuits are identified by the CIC and the Range subfield of the Range 

and Status parameter. 

For the CGB message, the affected circuits are identified by the CIC and the Range and Status parameter. 

If an initial address message has been sent for the affected circuit and after at least one backward message relating to 
that call has been received then: 
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If the final response (i.e. 200 OK (INVITE)) has already been sent, the I-MGCF shall send a BYE message. 

If the final response (i.e. 200 OK (INVITE)) has not already been sent, the I-MGCF shall send a SIP response 
with Status-Code 480 Temporarily Unavailable. 

A Reason header field containing the (Q.850) Cause Value of the REL message generated by the ISUP procedures shall 
be added to the SIP message (BYE or 480 response) to be sent by the SIP side of the I-MGCF. 



7.2.3.1.9a 



Receipt of REFER 
IM CN Subsystem 



CS Network 



REFER 

To: B 

-P-Asserted ID: A- 

Referto: C 

Method: INVITE 



403 Forbidden 



MGCF 



Figure 11a: Receipt of REFER method 

Upon receipt of a REFER request at the MGCF, the default behaviour of the I-MGCF is to reject the REFER request 
with a 403 Forbidden response. 

NOTE: The I-MGCF may also decide for example to execute the REFER request as specified in IETF 

RFC 3515 [75] as an operator option, but such handling is outside of the scope of the present document. 



7.2.3.1.10 



Autonomous Release at I-MGCF 



Table 10 shows the trigger events at the MGCF and the release initiated by the MGCF when the call is traversing from 
SIP to ISUP/BICC. 

A Reason header field containing the (Q.850) Cause Value of the REL message sent by the I-MGCF shall be added to 
the SIP Message (BYE request or final response) sent by the SIP side of the I-MGCF. 

Editor's Note: It is FFS whether to indicate the cause value for internal error in the network to the user. 
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Table 10: Autonomous Release at l-MGCF 



^SIP 
Response 


Trigger event 


REL^ 
cause parameter 


484 Address Incomplete 


Determination that insufficient digits received. 


Not sent. 


480 Temporarily Unavailable 


Congestion at the MGCF/Call is not routable. 


Not sent. 


BYE 


ISUP/BICC procedures result in release after 
answer 


According to ISUP/BICC 
procedures. 


BYE 


SIP procedures result in release after answer. 


127 (Interworking unspecified) 


500 Server Internal error 


Call release due to the ISUP/BICC compatibility 
procedure (NOTE) 


According to ISUP/BICC 
procedures. 


484 Address Incomplete 


Call release due to expiry of T7 within the 
ISUP/BICC procedures 


According to ISUP/BICC 
procedures. 


480 Temporarily Unavailable 


Call release due to expiry of T9 within the 
BICC/ISUP procedures 


According to BICC/ISUP 
procedures. 


480 Temporarily Unavailable. 


Other BICC/ISUP procedures result in release 
before answer. 


According to BICC/ISUP 
procedures. 


NOTE: MGCF receives unrecognized ISUP or BICC signalling information and determines that the call needs 
to be released based on the coding of the compatibility indicators, refer to ITU-T Recommendation 
Q.764 [4] and ITU-T Q.1 902.4 [30]. 



7.2.3.1 .1 1 Internal through connection of the bearer path 

The through connection procedure is described in subclause 9.2.2.3.5. 

7.2.3.2 Outgoing Call Interworking from ISUP to SIP at 0-MGCF 

7.2.3.2.1 Sending of INVITE 

7.2.3.2.1.1 General 



0-MGCF 



lAM 



INVITE 



Figure 11b: Receipt of an lAM 

Upon reception of an lAM message, the O-MGCF shall send a SIP INVITE request, as further detailed in the 
subclauses below. 

An O-MGCF shall support both the SIP preconditions and 100 rel extensions and indicate the support of the SIP 
preconditions and lOOrel extensions in the INVITE request, unless the Note below applies. 

NOTE: If the O-MGCF is deployed in an IMS network that by local configuration serves no user requiring 
preconditions, it may send the INVITE request without indicating support of preconditions. 



7.2.3.2.1.2 



Interaction with continuity check 



If the Continuity Check indicator in the Nature of Connection Indicators parameter in the incoming lAM is set to 
indicate either "continuity check required on this circuit" or "continuity check performed on previous circuit", the O- 
MGCF should defer sending the INVITE request until receiving a COT message. 
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NOTE: If the Continuity Check indicator in the Nature of Connection Indicators parameter in the incoming lAM 
is set to indicate either "continuity check required on this circuit" or "continuity check performed on 
previous circuit" and the O-MGCF sends the INVITE request before receiving a COT message, the 
following considerations apply: If the receiving terminal is not supporting the SIP precondition and the 
SIP UPDATE method, clipping may occur. Furthermore, if the MGCF sets the SDP "inactive" attribute in 
the initial INVITE request and the receiving terminal is not supporting the SIP precondition, the 
interworking procedures within the present specification do not describe all necessary signalling 
interactions required to set up a call, in particular with respect to the sending of the re-IN VITE that may 
also cause additional delay in the call setup. In addition, the interworking of the ringing indication might 
not be possible if the peer sends the ringing indication only as response to a re-INVITE. 



O-MGCF 



lAM 



COT 

"(NOTE)' 



INVITE 



NOTE: Waiting for the COT is recommended, if the Continuity Checl< indicator in the Nature of Connection 

Indicators parameter in the incoming lAIVI is set to indicate either "continuity check required on this circuit' 
or "continuity check performed on previous circuit' 

Figure 12: Receipt of an lAIV! (Waiting for the COT message) 



7.2.3.2.1.3 



lAM without calling party number 



If no calling party number is received in the incoming lAM message, as a network option, the O-MGCF may send an 
INR message to request the calling party number and not send the INVITE request until receiving an INF message with 
calling party number. If no calling party number is received in the INF message, O-MGCF may reject or continue the 
call based on local configuration. 

O-MGCF 





lAM 










INR 










INF 














INVITE 











Figure 12a: Receipt of an lAIV! (Request for calling party number) 
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7.2.3.2.1 .4 Terminating overlap signalling at MGCF 

0-MGCF 



lAM 


^ 


INVITE 




SAM 








w 


^ 






W 



Figure 13: Receipt of an lAIUI (Overlap signalling in CS network) 

After initiating the normal incoming BICC/ISUP call establishment procedures, determining the end of address 
signalling and selecting to route the call to the IMS domain, the O-MGCF shall send the initial INVITE. 

The end of address signalling shall be determined by the earlier of the following criteria: 

a) by receipt of an end-of -pulsing (ST) signal; or 

b) by receipt of the maximum number of digits used in the national numbering plan; or 

c) by analysis of the called party number to indicate that a sufficient number of digits has been received to route the 
call to the called party; or 

d) by observing that timer Ti/wl has expired after the receipt of the latest address message and the minimum 
number of digits required for routing the call have been received. 

If the end of the address signalling is determined in accordance with criteria a) b) or c), the timer Ti/w2 is started when 
INVITE is sent. Also, if the PSTN XML body is supported as a network option, the O-MGCF shall insert the PSTN 
XML sendingCompletelndication. 

7.2.3.2.1 .5 Fallback (optional) 

The Fallback mechanism described in the present subclause shall only apply if the O-MGCF supports the PSTN XML 
body as a network option, and propagates UDI-TA fallback signalling into the IMS as a network option. 

NOTE: If the Fallback related signalling is not forwarded according to the procedures in the present sublause by 
the O-MGCF, the O-MGCF will apply the ISUP Fallback procedures when the lAM includes a TMR and 
a TMR prime parameter and a USI and USI Prime parameter. 

When the lAM includes a TMR and a TMR prime parameter and a USI and USI Prime parameter then the O-MGCF 
shall: 

map the "USI Prime" into the "InformationTransferCapability" of the second BearerCapability element in the 
PSTN XML body; 

include SDP with one m-line of "audio" media type in the INVITE; 

map the "TMR" and "USI Prime" into a first offerered format in the SDP m-line according to table 10b; 

- map the "USI" into the first Bearer Capability element in the PSTN XML body; 

map the "TMR prime" into the "InformationTransferCapability" of the first BearerCapability element in the 
PSTN XML body; and 

map the TMR prime and USI into a second offerered format in the SDP m-line according to table 10b. 
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7.2.3.2.1a Sending of INVITE without determining the end of address signalling 

7.2.3.2.1 a.1 General 

As a network option, the O-MGCF is not required to determine the end of address signalHng. In this case the O-MGCF 
shall send an initial INVITE when a preconfigured number of digits has been reached. 

When the MGCF receives ISUP SAM messages the additional digits received in the S AMs may either be sent using the 
in-dialog overlap method as specified in subclause 7.2.3.2.1a.2 or using the multiple INVITEs overlap method as 
specified in 7.2.3.2. la. 3. It depends on the network configuration which of these methods is applied. However, within 
one IMS only a single method shall be used. 

7.2.3.2.1 a. 2 Additional digits sent with in-dialog overlap method 

O-MGCF 



lAM 






INVITE 








fc. 


SAM 




404/484 






INVITE 














18x 




SAM 




INFO 










200 (INFO) 


"^ 











Figure 14: Overlap signalling using in-dialog INFOs in CS an IMS network 

If the O-MGCF sends an initial SIP INVITE request before the end of address signalling is determined, the O-MGCF 
shall: 

use the SIP precondition extension within the SIP INVITE request; 

start timer Ti/w2; 

be prepared to process SAM as described below; 

be prepared to handle incoming SIP 18x provisional responses, establishing early dialogs; and 

be prepared to handle incoming SIP 404 or 484 error responses as detailed in subclause 7.2.3.2. 12. 1 . 

NOTE: A SIP INVITE request with incomplete address information can be rejected with a SIP 404 or 484 error 
response. 

On receipt of a SAM from the BICC/ISUP side, unless the O-MGCF has received a SIP 180 (Ringing) response for the 
call, the following O-MGCF procedures apply: 

The O-MGCF shall stop timer Ti/w3 (if it is running). 

If no response has been received for the previous INVITE request of the same call, the O-MGCF shall wait for 
the response and then apply the procedures in the next bullets to transfer the digits received in the SAM. If 
additional SAMs are received while the O-MGCF is waiting for the response for the previous SIP INVITE 
request, the digits within shall be combined with the digits of the previous SAMs. 

If an early dialog has not been established, and a SIP 404 or 484 error response has been received for the last 
previous SIP INVITE request for the same call, the O-MGCF shall send a SIP INVITE request complying to the 
following: 
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The SIP INVITE request shall use the SIP preconditions extension. 

The SIP INVITE request shall include all digits received so far for this call in the Request-URI. 

The SIP INVITE request shall include the same Call-ID and From tag as the previous SIP INVITE request 
for the call. 

If an early dialog has been established, and a response has been received for any previously sent SIP INFO 
request, the O-MGCF shall send an in-dialog SIP INFO request complying the following: 

The SIP INFO request shall only include the digits received since the previous SIP request with digits was 
sent (see Note). 

If no response has been received for the previous SIP INFO request, the O-MGCF shall wait for the response and 
then apply the procedures in the previous bullet to transfer digits received in the SAM. If additional SAMs are 
received while the O-MGCF is waiting for the response for the previous SIP INFO request, the digits within 
shall be combined with the digits of the previous SAMs. 

Restart Ti/w2. 

If timer Ti/w2 has expired, or the O-MGCF has received a SIP 180 (Ringing) response for the call, the O-MGCF shall 
ignore subsequent SAMs received. 

NOTE: The encoding of the digits within the SIP INFO request is described in subclause 7.2.3.2.20.2. 

Editor's note: It needs to be verified whether the timer procedures associated with the in-dialog method are correct. 

7.2.3.2.1 a. 3 Additional digits sent using tine multiple INVITEs overlap method 



O-MGCF 



lAM 






INVITE 














404/484 




SAM 




INVIIH 














404/484 




SAM 




INVIIH 












^ 



Figure 14a: Overlap signalling using multiple INVITEs in CS an IMS network 

If the O-MGCF sends an SIP INVITE request before the end of address signalling is determined, the O-MGCF shall: 

use the SIP precondition extension within the SIP INVITE request; 

start timer Ti/w2; and 

be prepared to process SAM as described below; and 

be prepared to handle incoming SIP 404 or 484 error responses as detailed in subclause 7.2.3.2. 12. 1 . 

NOTE: An SIP INVITE request with incomplete address information will be rejected with a SIP 404 or 484 error 
response. 

On receipt of a SAM from the BICC/ISUP side, unless the O-MGCF has received a SIP 180 (Ringing) response for the 
call, the O-MGCF shall: 
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stop timer Ti/w3 (if it is running); 

send an INVITE request complying to the following: 

The SIP INVITE request shall use the SIP preconditions extension. 

The SIP INVITE request shall include all digits received so far for this call in the Request-URI. 

The SIP INVITE request shall include the same Call-ID and From tag as the previous SIP INVITE request 
for the call. 

restart Ti/w2; 

If timer Ti/w2 has expired, or the O-MGCF has received a SIP 180 (Ringing) response for the call, the O-MGCF shall 
ignore subsequent SAMs received. 

7.2.3.2.2 Coding of the INVITE 

7.2.3.2.2.0 Overview 

Table lOaa provides a summary of how the header fields within the outgoing INVITE message are populated. 

Table 10aa: Interworked contents of the INVITE message 



lAM^ 


INVITE^ 


Called Party Number 


Request-URI 
To 


Calling Party Number 


P-Asserted-ldentity 


Privacy 


From 


Generic Number {"additional calling party number') 


From 


Privacy 


Hop Counter 


IVIax-Forwards 


TMR/USI 


Message Body (application/SDP) 


Location Number 


P-Access-Network-lnfo 



7.2.3.2.2.1 



REQUEST URI Header 



The called party number parameter of the lAM message is used to derive Request URI of the INVITE Request. The 
Request URI is a tel URI or SIP URI with "user=phone" and shall contain: 

an E.164 International public telecommunication number prefixed by a "+" sign (e.g. tel:H-4911231234567), or 

a non E.164 number (national operator option for service numbers), expressed as a local number as per IETF 
RFC 3966 [97]. 



£75/ 



3GPP TS 29.163 version 9.13.0 Release 9 



69 



ETSI TS 129 163 V9.13.0 (2013-04) 



Table 10a: Mapping ISUP Called Party Number to 
SIP Request-URI and To header field 



lAM 


INVITE 1 


BICC/ISUP 
Parameter / field 


Value 


SIP component 


Value 


Called Party Number 
(NOTE 3) 




Request-URI and To 
header field 


display-name (optional) and addr-spec 
derived from Called Party Number parameter 
address signals 


Nature of Address 
Indicator (NOTE 2) 
(NOTE 6) 


"national (significant) 
numbei" 


TelURIorSIPURI 


Insert "+CC" before the Address signals 
(N0TE1) 


"internationai 
numbei" 


Insert "+" before the Address signals 


"Networi<-specific 
number" or 
"reserved for national 
use" 


according to local policies should either be: 

- a global number (-i-CC), if the called party 
number may be converted into an E.164 
address 

OR, depending on operator"s requirements 
may be converted into 

- local number (with a phone-context 
parameter) (NOTE 4) (NOTE 5) 


NOTE 1 : CC = Country Code of the network in which the 0-MGCF is located. 

NOTE 2: The usage of "Nature of address indicator" value "unknown" is allowed but the mapping is not specified in 

the present specification. 
NOTE 3: If the address signals received in the ISUP Called Party Number contain a sending terminated signal 

(hexadecimal digit F), then this shall be discarded or if the 0-MGCF supports the PSTN XML body as a 

network option then the PSTN XML sendingCompletelndication shall be set. 
NOTE 4: Mapping between nature of address indicator values and phone-context values is provisioned in the MGCF. 

Setting of value of phone-context is depending on local operator's policies. 
NOTE 5: Network-specific number or reserved for national use shall be translated into E.164 format numbers except if 

local operator"s policy requires keeping in local format (e.g. for national reasons E.164 numbers cannot be 

used for such purpose). In the later case the mapping shall be done as indicated in the table. 
NOTE 6: The values "Network routing number in national (significant) number format", "Network routing number in 

network specific number format" or "Network routing number concatenated with called directory number" are 

used when number portability is supported. For the mapping see section 7.2.3. 2.2A. 



7.2.3.2.2.2 



SDR Media Description 



If the O-MGCF indicates support of the SIP preconditions in the initial INVITE request and local preconditions have 
not been met, the SDP media description shall contain precondition information as per 3GPP TS 24.229 [9]. Depending 
on the coding of the continuity indicators different precondition information (IETF RFC 3312 [37]) is included. If the 
continuity indicator indicates "continuity performed on a previous circuit" or "continuity required on this circuit", and 
the INVITE is sent before receiving a COT message (which is not recommended according to subclause 7.2.3.2.1.1), 
then the O-MGCF shall indicate that the preconditions are not met. Otherwise the O-MGCF shall indicate whether the 
preconditions are met, dependent on the status of the local resource reservation. If the local preconditions are not met 
the O-MGCF should set the media stream to inactive mode (by including an attribute "a=inactive"). If the local 
configuration indicates that O-MGCF is deployed in the IMS network that serves users supporting SIP precondition 
mechanism, the attribute "a=inactive" may be omitted when the initial SDP offer indicates local preconditions are not 
met. If the initial SDP offer indicates local preconditions are fulfilled, the O-MGCF shall not set the media stream to 
inactive mode. 

If the O-MGCF determines that a speech call is incoming, the O-MGCF shall include the AMR codec transported 
according to IETF RFC 4867 [23] with the options listed in subclause 5.1.1 of 3GPP TS 26.236 [32] in the SDP offer, 
unless the Note below applies. Within the SDP offer, the O-MGCF should also provide SDP RR and RS bandwidth 
modifiers specified in IETF RFC 3556 [59] to disable RTCP, as detailed in subclause 7.4 of 3GPP TS 26.236 [32]. The 
O-MGCF may include other codecs according to operator policy. 

NOTE: If the O-MGCF is deployed in an IMS network that by local configuration serves no user equipment that 
implements the AMR codec, then the AMR codec may be excluded from the SDP offer. 

To avoid transcoding or to support non-speech services, the O-MGCF may add media derived from the incoming ISUP 
information according to table 10b. The support of the media listed in table 10b is optional. If the O-MGCF supports the 
PSTN XML body as a network option and adds media derived from the incoming ISUP information according to table 
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10b, the O-MGCF shall also map the media related ISUP information into the XML body as shown in table 

7.2.3.2.2.7.1. 
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Table 10b: Coding of SDP media description lines from TMR/USI: ISUP to SIP 



TMR parameter 


USI parameter (Optional) 


HLC IE in ATP 
(Optional) 


m= line 


b= line 


a= line 


TMR codes 


Information 
Transfer- 
Capability 


User Information 

Layer 1 Protocol 

Indicator 


High Layer 

Characteristics 

Identification 


<media> 


<transport> 


<fmt-list> 


<modifier>: 

<bandwidth- 

value> 


rtpmap:<dynamic-PT> <encoding 

name>/<clock rate>[/encoding 

parameters> 


"speech" 


"Speech" 


"G.71 1 ij-law" 


Ignore 


audio 


RTP/AVP 


(and possibly 8) 
(NOTE 1) 


AS: (64 + 
RTP/U DP/IP 
overhead) 


rtpmap:0 PCMU/8000 

(and possibly rtpmap:8 PCMA/8000) 

(NOTE 1) 


"speech" 


"Speech" 


"G.711 ij-law" 


Ignore 


audio 


RTP/AVP 


Dynamic PT (and 
possibly a second 
Dynamic PT) 
(NOTE 1) 


AS: (64 + 
RTP/U DP/IP 
overhead) 


rtpmap:<dynamic-PT> PCMU/8000 
(and possibly rtpmap:<dynamic-PT> 
PCMA/8000) 
(NOTE 1) 


"speech" 


"Speech" 


"G.711 A-law" 


Ignore 


audio 


RTP/AVP 


8 


AS: (64 + 
RTP/U DP/IP 
overhead) 


rtpmap:8 PCMA/8000 


"speech" 


"Speech" 


"G.711 A-iaw" 


Ignore 


audio 


RTP/AVP 


Dynamic PT 


AS:(64 + 
RTP/U DP/IP 
overhead) 


rtpmap:<dynamic-PT> PCIVIA/8000 


"3.1 KHz audio" 


USI Absent 




Ignore 


audio 


RTP/AVP 


8 


AS:(64 + 
RTP/U DP/IP 
overhead) 


rtpmap:8 PCMA/8000 


"3.1 KHz audio" 


"3.1 KHz audio" 


"G.711 ii-iaw" 


(NOTE 3) 


audio 


RTP/AVP 


(and possibly 8) 
(N0TE1) 


AS:(64 + 
RTP/U DP/IP 
overhead) 


rtpmap:0 PCMU/8000 

(and possibly rtpmap:8 PCMA/8000) 

(NOTE 1) 


"3.1 KHz audio" 


"3.1 KHz audio" 


"G.711 A-iaw" 


(NOTE 3) 


audio 


RTP/AVP 


8 


AS:(64 + 
RTP/U DP/IP 
overhead) 


rtpmap:8 PCMA/8000 


"3.1 KHz audio" 


"3.1 KHz audio" 




"Facsimile 
Group 2/3" 


image 


UdptI [73] 


t38[73] 


AS:(64 + 

UDP/IP 

overhead) 


Based on ITU-T T.38 [72]. 


"3.1 KHz audio" 


"3.1 KHz audio" 




"Facsimile 
Group 2/3" 


image 


tcp 


t38[73] 


AS:(64 + 

TCP/IP 

overhead) 


Based on ITU-T T.38 [72]. 


"64 l<bit/s 
preferred" 


"Speech/ 
3.1 KHz audio" 
(NOTE 6) 


N/A 


Ignore 


audio 


RTP/AVP 


Dynamic PT 


AS:(64 + 
RTP/U DP/IP 
overhead) 


rtpmap:<dynamic-PT> 
CLEARMODE/8000 
(NOTE 2)(N0TE 4) 


"64 kbit/s 
unrestricted" 


"Unrestricted 

digital 

information" 


N/A 


Ignore 


audio 


RTP/AVP 


Dynamic PT 


AS:(64 + 
RTP/U DP/IP 
overhead) 


rtpmap:<dynamic-PT> 
CLEARMODE/8000 
(NOTE 2)(N0TE 5) 


NOTE 1 : Both PCMA and PCMU could be required. 
NOTE 2: CLEARMODE is specified in IETF RFC 4040 [69]. 

NOTE 3: HLC is normally absent in this case. It is possible for HLC to be present with the value "Telephony", although 6.3.1/Q.939 indicates that this would normally be 
accompanied by a value of "Speech" for the Information Transfer Capability element. 



£75/ 



3GPP TS 29.163 version 9.13.0 Release 9 



72 



ETSI TS 129 163 V9.13.0 (2013-04) 



TMR parameter 


USI parameter (Optional) 


HLC IE in ATP 
(Optional) 


m= line 


b= line 


a= line 


TMR codes 


Information 
Transfer- 
Capability 


User Information 

Layer 1 Protocol 

Indicator 


High Layer 

Characteristics 

Identification 


<media> 


<transport> 


<fmt-list> 


<modifier>: 

<bandwidth- 

value> 


rtpmap;<dynamic-PT> <encoding 

name>/<clock rate>[/encoding 

parameters> 


NOTE 4: After the CLEARMODE codec, additional speech codecs such as AMR and/or G.722 and/or G.71 1 available via transcoding or reframing should be offered in the 

same m-line. 
NOTE 5: As alternative or in addition to the m-line containing the CLEARMODE codec, an MGCF supporting the multimedia interworking detailed in Annex E may add an m-line 

for speech codecs and an m-line for video codecs as detailed in this Annex. 
NOTE 6: In this case, the USI prime parameter will also be present and will indicate "Unrestricted Digital Information with tones/announcements". 



£75/ 



3GPP TS 29.163 version 9.13.0 Release 9 



73 



ETSI TS 129 163 V9.13.0 (2013-04) 



7.2.3.2.2.3 



P-Asserted-ldentity, From and Privacy header fields 



Table 12: Mapping BICC/ISUP CLI parameters to SIP header fields 



Has a Calling Party 

Number parameter 

with complete E.164 

number, and with 

Screening Indicator = 

UPVPorNP(NOTEI) 

been received? 


Calling 
Party 

Number 
APRI 


Has a Generic 
Number (ACgPN) 

with a complete 
E.164 number and 

with Screening 
Indicator = UPNV 

been received? 


Generic 

Number 

APRI 


P-Asserted-ldentity 
header field 


From header field 


Privacy header field 


N 




N 




Header field not included 


SIP or SIPS URI with addr-spec 
of Unavailable User Identity 
(NOTE 2) (NOTE 6) 


Header field not included 


N 




Y (NOTE 3) 


"presentation 
allowed" 


Header field not included 


addr-spec derived from Generic 

Number (ACgPN) address 

signals 

or network provided value 

(NOTE 6) 


Header field not included 


N 




Y (NOTE 3) 


"presentation 
restricted" 


Header field not included 


SIP or SIPS URI with addr-spec 
of Unavailable User Identity 
(NOTE 2) (NOTE 6) 


Header field not included 


Derived from the Generic 
Number parameter address 
signals (see table 13) (NOTE 8) 


priv-value =: "user" 
(See table 16). 


Y 


"presentation 
allowed" 


N 




Derived from Calling Party 
Number parameter 
address signals 
(See table 14) 


Tel URI or SIP URI derived from 
Calling Party Number parameter 
address signals (See table 15) 


Privacy header is not 
included or if included, "id" is 
not included (See table 16) 


Y 


"presentation 
allowed" 


Y 


"presentation 
allowed" 


Derived from Calling Party 
Number parameter 
address signals 
(See table 14) 


Derived from Generic Number 
(ACgPN) address signals 
(See table 13) 
(NOTE 6) 


Privacy header is not 
included or if included, "id" 
and "user" are not included 
(See table 16) 


Y 


"presentation 
allowed" 


Y 


"presentation 
restricted" 


Derived from Calling Party 
Number parameter 
address signals 
(See table 14) 


Tel URI or SIP URI derived from 
Calling Party Number parameter 
address signals (See table 15) 
(NOTE 9) 


Privacy header is not 
included or if included, "id" is 
not included 
(See table 16) 


SIP or SIPS URI with addr-spec 
of Anonymuous URI (NOTE 6) 
(NOTE 7) (NOTE 10) 


Privacy header is not 
included or if included, "id" is 
not included 
(See table 16). 


Derived from the Generic 
Number parameter address 
signals (see table 13) (NOTE 8) 


priv-value =: "user", 
"id" is not included 
(See table 16). 
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Has a Calling Party 

Number parameter 

with complete E.164 

number, and with 

Screening Indicator = 

UPVPorNP(NOTEI) 

been received? 


Calling 
Party 

Number 
APRI 


Has a Generic 
Number (ACgPN) 

with a complete 
E.164 number and 

with Screening 
Indicator = UPNV 

been received? 


Generic 

Number 

APRI 


P-Asserted-ldentity 
header field 


From header field 


Privacy header field 


Y 


"presentation 
restricted" 


N 




Derived from Calling Party 
Number parameter 
address signals 
(See table 14) 


SIP or SIPS URI with addr-spec 
of Anonymous URI (NOTE 7) 
(NOTE 6) 


priv-value =: "id". (See table 
16) 


Y 


"presentation 
restricted" 


Y 


"presentation 
allowed" 


Derived from Calling Party 
Number parameter 
address signals 
(See table 14) 


Derived from Generic Number 
(ACgPN) address signals 
(See table 13) 
(NOTE 6) 


priv-value =: "id". 


Y 


"presentation 
restricted" 


Y 


"presentation 
restricted" 


Derived from Calling Party 
Number parameter 
address signals 
(See table 14) 


SIP or SIPS URI with addr-spec 
of Anonymous URI (NOTE 7) 
(NOTE 6) (NOTE 10) 


priv-value =: "id". 


Derived from the Generic 
Number parameter address 
signals (see table 13) (NOTE 8) 


priv-value =: "id", "user". 
(See table 16). 


Y 


"presentation 
restricted by 
networl<" 
(NOTE 4) 


N 




Header field not included. 


addr-spec is set to 
"unavailable@hostportion" 
(NOTE 5) 


Privacy header is not 
included or if included, "id" is 
not included (See table 16) 


Y 


"presentation 
restricted by 
networl<" 


Y 


"presentation 
allowed" 


Header field not included. 


Derived from Generic Number 
(ACgPN) address signals 
(See table 13) 
(NOTE 6) 


Privacy header is not 
included or if included, "id" 
and "user" are not included 
(See table 16) 


Y 


"presentation 
restricted by 
networl<" 


Y 


"presentation 
restricted" 


Header field not included. 


addr-spec is set to 
"unavailable@hostportion" 
(NOTE 5) 


Privacy header is not 
included or if included, "id" is 
not included 
(See table 16) 


Derived from the Generic 
Number parameter address 
signals (see table 13) (NOTE 8) 


priv-value =: "user", 
"id" is not included 
(See table 16). 
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Has a Calling Party 


Calling 


Has a Generic 


Generic 


P-Asserted-ldentity 


Number parameter 


Party 


Number (ACgPN) 


Number 


header field 


with complete E.164 


Number 


with a complete 


APRI 




number, and with 


APR! 


E.164 number and 






Screening Indicator = 




with Screening 






UPVPorNP(NOTEI) 




Indicator = UPNV 






been received? 




been received? 







From header field 



Privacy header field 



NOTE 1 : 



NOTE 2: 

NOTES 
NOTE 4 
NOTES 
NOTE 6 
NOTE 7 

NOTE 8: 



NOTE 9: 



NOTE 10 



A Network Provided CLI in the CgPN parameter may occur on a call to IMS. Therefore in order to allow the "display" of this Network Provided CLI at a SIP UAS it shall 

be mapped into the SIP From header. It is also considered suitable to map into the P-Asserted-ldentity header since in this context it is a fully authenticated CLI 

related exclusively to the calling line, and therefore as valid as a User Provided Verified and Passed CLI for this purpose. 

The "From" header may contain an "Unavailable User Identity". An "Unavailable User Identity" includes information that does not point to the calling party and 

indicates that the caller's identity is unknown. The encoding of the "Unavailable User Identity" shall be as defined in 3GPP TS 23.003 [74]. 

This combination of CgPN and ACgPN is an error case but is shown here to ensure consistent mapping across different implementations. 

This is an ETSI specific value described within ETSI EN 300 356-1 [70]. 

The setting of the hostportion is according to operator policy. 

In accordance with IETF RFC 3261 [19] procedures, a tag shall be added to the "From" header. 

The "From" header may contain an "Anonymous User Identity". An "Anonymous User Identity" includes information that does not point to the calling party and 

indicates that the caller has withheld their identity. The encoding of the "Anonymous User Identity" shall be as defined in 3GPP TS 23.003 [74]. 

As a network option, the "From" header may be derived from the Generic Number parameter address signals (see table 13). This option is only recommended to use 

within a trusted domain where an entity such as a TAS is configured to be inserted into the call path that is able to change the "From" Header content to an 

anonymous user identity (NOTE 7). 

As a network option, the "From" header may be derived from the Calling Party Number parameter address signals (see table 15). This option is only recommended 

to use within a trusted domain where an entity such as a TAS is configured to be inserted into the call path that is able to change the "From" Header content to an 

anonymous user identity (NOTE 7). 

Network option. 
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Table 13: Mapping of generic number (additional calling party number) to SIP from header fields 



BICC/ISUP parameter / 
field 


Value 


SIP component 


Value 


Generic Number 
Number Qualifier 
Indicator 


"additional calling party 
numbei" 


From header field 


display-name (optional) and 
addr-spec 


Nature of Address 
Indicator 


"national (significant) 
numbei" 


Tel URI or SIP URI 


Add CC (of the country where 
the MGCF is located) to GN 
address signals to construct 
E.1 64 number in URI. Prefix 
number with "+". 


"international numbei" 


Map complete GN address 
signals to E.1 64 number in 
URI. Prefix number with "+". 


Address signal 


if NOA is "national 
(significant) numbei" then 
the format of the address 
signals is: 
NDC+ SN 

If NOA is "international 
numbei" 

then the format of the 
address signals is: 
CC + NDC + SN 






Tel URI or SIP URI 


CC+NDC+SNasE.164 
number in URI. Prefix number 
with "+". 



Table 14: Mapping of calling party number parameter to SIP P-Asserted-ldentity header fields 



BICC/ISUP Parameter/ 
field 


Value 


SIP component 


Value 


Calling Party Number 




P-Asserted-ldentity header 
field 




Nature of Address 
Indicator 


"national (significant) 
numbei" 


Tel URI or SIP URI 


Add CC (of the country 
where the MGCF is 
located) to CgPN address 
signals to construct E.1 64 
number in URI. Prefix 
number with "+". 


"international numbei" 


Map complete CgPN 
address signals to E.1 64 
number in URI. Prefix 
number with "+". 


Address signal 


If NOA is "national 

(significant) numbei" then 

the format of the address 

signals is: 

NDC + SN 

If NOA is "international 

numbei" 

then the format of the 

address signals is: 

CC + NDC + SN 
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Table 15: Mapping of BICC/ISUP Calling Party Number parameter to SIP From header fields 



BICC/ISUP parameter / 
field 


Value 


SIP component 


Value 


Calling Party Number 




From header field 




Nature of Address 
Indicator 


"national (significant) 
numbei" 


Tel URI or SIP URI 
(NOTE) 


Add CC (of the country 
where the MGCF is 
located) to CgPN address 
signals then map to 
construct E.164 number in 
URI. Prefix number with 


"internationai number" 


IVIap complete CgPN 
address signals to 
construct E.164 number in 
URI. Prefix number with 


Address signal 


If NOA is "national 
(significant) number" then 
the format of the address 
signals is: 
NDC + SN 

If NOA is "international 
numbei" 

then the format of the 
address signals is: 
CC + NDC + SN 


Tel URI or SIP URI 
(NOTE) 


CC+NDC+SN as E.164 
number in URI. Prefix 
number with "+". 


NOTE: A tel URI or a SIP URI with "user=phone" is used according to operator policy. 



Table 16: IVIapping of BICC/ISUP APRIs into SIP Privacy header fields 



BICC/ISUP parameter / 
field 


Value 


SIP component 


Value 


Calling Party Number 




Privacy header field 


priv-value 


APRI 


"presentation restricted' 


Priv-value 


"id" 

("id" included only if the P- 

Asserted-ldentity header is 

included in the SIP 

INVITE) 


"presentation allowed' or 
"presentation restricted by 
network' 


Priv-value 


omit Privacy header 
or Privacy header without 
"id" if other privacy service 
is needed 


Generic Number (ACgPN) 




Privacy header field 


priv-value 


APRI (NOTE) 


"presentation restricted" 


Priv-value 


"user" 


"presentation allowed" 


Priv-value 


omit Privacy header 
or Privacy header without 
"user" if other privacy 
service is needed 


NOTE: IVIapping of Generic Number APRI is only applicable, if the Generic Number is mapped to the "From" 
header field (see table 12). 



7.2.3.2.2.3A 



"cpc" URI Parameter in P-Asserted-ldentity Header 



See Annex C for normative interworking of a Calling party's category to a "cpc" URI parameter within P-Asserted- 
Identity header field. 

7.2.3.2.2.3B "oli" URI Parameter in P-Asserted-ldentity Header 

See Annex H for normative interworking of the "oli" URI parameter as a network option. 
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7.2.3.2.2.4 Max Forwards header 

If the Hop Counter procedure is supported in the CS network, the O-MGCF shall use the Hop Counter parameter to 
derive the Max-Forwards SIP header. Due to the different default values (that are based on network 
demands/provisions) of the SIP Max-Forwards header and the Hop Counter, an adaptation mechanism shall be used to 
adopt the Hop Counter to the Max Forwards at the O-MGCF. For example, the following guidelines could be applied. 

a) Max-Forwards for a given message should be monotone decreasing with each successive visit to a SIP entity, 
regardless of intervening interworking, and similarly for Hop Counter. 

b) The initial and successively mapped values of Max-Forwards should be large enough to accommodate the 
maximum number of hops that may be expected of a validly routed call. 

The table 17 shows the principle of the mapping: 

Table 17: Hop counter-Max forwards 



Hop Counter | = X | Max-Forwards I = Y = Integer part of (X * Factor) 



NOTE: The Mapping of value X to Y should be done with the used (implemented) adaptation mechanism. 



The factor used to map from Hop Counter to Max-Forwards for a given call will depend on call origin, and will be 
provisioned at the O-MGCF based on network topology, trust domain rules, and bilateral agreement. 

The Principle of adaptation could be implemented on a basis of the network provision, trust domain rules and bilateral 
agreement. 

7.2.3.2.2.5 IMS Communication Service Identifier 

For speech and video calls, the O-MGCF shall insert an IMS Communication Service Identifier, indicating the IMS 
Multimedia Telephony Communication Service. 

The IMS Communication Service Identifier for the IMS Multimedia Telephony Communication Service is defined in 
3GPPTS 24.173 [88]. 

7.2.3.2.2.6 P-Early-Media Ineader field 

For a speech call the O-MGCF may include the P-Early-Media header field with the "supported" parameter as described 
in IETF RFC 5009 [89] in each outgoing INVITE request. 

NOTE: The P-Early-Media header with the "supported" parameter can be ignored by terminating devices when 
not supporting the procedures described in IETF RFC 5009 [89]. 

7.2.3.2.2.7 PSTN XML elements 

If the O-MGCF supports the PSTN XML body as a network option, the O-MGCF shall map ISUP information into the 
XML body as shown in table 7.2.3.2.2.7.1 and 7.2.3.2.2.8.1. 



£75/ 



3GPP TS 29.163 version 9.13.0 Release 9 



79 



ETSI TS 129 163 V9.13.0 (2013-04) 



Table 7.2.3.2.2.7.1 : Mapping of ISUP Parameters with PSTN XIUIL elements 



lAM^ 


INVITE -^ 


ISUP Parameter 


Content 


PSTN XML 


Access Transport Parameter 


High layer compatibility 


HighLayerCompatibility (NOTE 1, 
NOTE 2, NOTE 3) 


Low layer compatibility 


LowLayerCompatibility (NOTE 3) 


User Service Information 




Bearer Capability (NOTE 3, NOTE 4) 


User Teleservice Information 


High layer compatibility 


HighLayerCompatibility (NOTE 2, 
NOTE 3) 


Called Party Number 


Sending terminated signal 
(hexadecimal digit F) 


sendingCompletelndication 


NOTE 1 : If two high layer compatibility information elements are received in the ATP of the lAM, they shall be 
transferred in the same order as received into the PSTN XIVIL body within the INVITE. 

NOTE 2: In the normal case, the High layer compatibility information in the ATP is equal to the High layer 

compatibility in the User Teleservice Information parameter. In the PSTN XML body, no two identical High 
layer compatibility information shall be present. If an HLC is available both in the ATP and in the User 
Teleservice information, the HLC from the ATP should be mapped. 

NOTE 3: The 0-MGCF shall only map this information element if the 0-IVIGCF offers media formats which can be 
transferred by the IIVI-MGW without transcoding and are derived from the incoming ISUP information 
according to table 10b. 

NOTE 4: See subclause 7.2.3.2.1.5. 



7.2.3.2.2.8 



Progress indicator 



If the O-MGCF supports the PSTN XML body as a network option, the Forward call indicators parameter and an 
available "Progress indicator" element in the lAM shall be mapped into a Progresslndicator in the PSTN XML body of 
the INVITE as shown in table 7.2.3.2.2.8.1. 

Table 7.2.3.2.2.8.1 : Coding of PSTN XML Progresslndicator 



lAM^ 


INVITE -^ 


Forward call indicators parameter 


Access transport 
parameter 


PSTN XML body with 
Progresslndicator with 
"Progress Description" 
value No. (Value of PI) 


ISDN User Part indicator 


ISDN access indicator 




("ISDN User Part 

not used all the way") 


Value non-significant 


Value non- 
significant 


No. 1 (N0TE1) 


1 
("ISDN User Part 
used all the way") 


0("originating access non - ISDN") 


Value non- 
significant 


No. 3 (NOTE 1) 


1 
("ISDN User Part 
used all the way") 


1 
("originating access ISDN") 


Progress indicator 
No. (Value of PI) 


Progresslndicator 

mapped from Progress 

indicator received in the 

ATP (NOTE 2) and 

additional 

Progresslndicator with 

"Progress Description" 

value No.6 (NOTE 1, 

NOTE 3) 


1 
("ISDN User Part 
used all the way") 


1 
("originating access ISDN") 


Not present 


No. 6 (NOTE 1) 


NOTE 1 : The Progresslndicator "Coding Standard" parameter shall be set to "00 (ITU-T standardized coding)". The 
default value for the Progresslndicator "Location" parameter is "001 1 (Transit Network)". 

NOTE 2: The entire Progress indicator, including the "Progress Description", "Coding Standard" and "Location" 
parameters shall be copied. 

NOTE 3: The order of Progresslndicators within PSTN XIVIL body is irrelevant. 
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7.2.3.2.2.9 



P-Access-Network-lnfo 



If the lAM message includes a location number ISDN user part parameter, the O-MGCF shall include a P-Access- 
Network-Info header. The P-Access-Network-Info shall be populated as shown in table 7.2.3.2.2.9.1. 

Table 7.2.3.2.2.9.1 : Coding of the P-Access-Network-lnfo header fields 



BICC/ISUP parameter / field 


SIP component 


Value 


Location Number 


access-type 


"GSTN" 


gstn-location 


value of Location Number, in quotes 



Table 7.2.3.2.2.9.2: Mapping ISUP Location Number to SIP P-Access-Network-lnfo 



lAM 


INVITE 


Location Number 


P-Access-Network-lnfo 


Parameter name 


not mapped 


Parameter length 


not mapped 


Parameter content 


gstn-location set to the hexadecimal representation of the ISUP parameter 
content, encoded as a text string between quotes 


NOTE 1 : As specified in ITU-T Q.763 [4], the parameter content includes both the header fields (octets 1 and 2) and 

the address signals. 
NOTE 2: The parameter content includes the address presentation restricted indicator. This field is not mapped to the 

Privacy header field. It is upon network operator responsibility to remove the P-Access-Network-lnfo header 

field when leaving the trust domain, as specified in 3GPP TS 24.229 [9]. 
NOTE 3: If the screening indicator is set to network provided, a np parameter is added to the P-Access-Network-lnfo 

header field value. 



7.2.3. 2. 2A Coding of the INVITE when Number Portability is supported 

This subclause describes optional coding procedures when Number Portability is supported. 



7.2.3.2.2A.1 



REQUEST URI and To Header 



When Number Portability is supported, the method used for signalling of the Called Party E. 164 address and the 
Number Portability Routing Number determines the parameters of the lAM message used to derive the Request URI of 
the INVITE Request. 

The number portability information (m and npdi) shall not be mapped into the To header field. 

ITU-T Q. 769.1 [92] describes three possible addressing methods for signalling of the Called Party E.164 address and 
Number Portability Routing Number (ITU-T Q.769.1 [92] uses the terms directory number and network routing number 
respectively). The choice of these methods is based on network operator and national requirements. 

The following subclauses describe how the Request URI and To header fields are populated, based on these methods, 
when a Number Portability Routing Number is available in the lAM. 

When the optional Number Portability Routing Number is available and supported, these procedures take precedence 
over procedures for coding of the Request URI and To header fields described in subclause 7.2.3.2.2.1. 

When a Number Portability Routing Number is not available, the Request URI and To Header fields are populated as 
described in subclause 7.2.3.2.2.1, with the following addition: If a Number Portability Forward Information Parameter 
parameter is present in the lAM, containing a value of "number portability query done for called number, non-ported 
called subscriber", a tel URI npdi parameter [93] is added. 

For the following subclauses, the Request URI is a tel URI or SIP URI with "user=phone" and shall contain an 
International public telecommunication number prefixed by a "+" sign (e.g. tel:H-49 11 23 1234567). 
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7.2.3.2.2A.1.1 



Separate Directory Number Addressing Metinod 



Table 17a: Mapping ISUP to SIP Request-URI and To header field with Number Portability Separate 

Directory Number Addressing Method 



lAM^ 


INVITE 


Called Party Number 


Called Directory Number 


Request-URI and To Header Field 


Address Signal: 

Nature of address indicator: 

"Network routing number in 
national (significant) number 
format" or "National 
(significant) number" or 
"Network routing number in 
network specific number 
format" as described in ITU-T 
Q.769.1 [92] 
(NOTE 2) 


Address Signal: 

Nature of address indicator: 

"National (significant) number". 


The "telephone-subscriber" is populated from 
the Called Directory Number as follows: 

Insert "+CC" before the Address signals (NOTE 1) 

The Tel URI rn= parameter is populated from 
the Called Party Number as follows: 

Insert "+CC" before the Address signals (NOTE 1) 
and is added only to the Request-URI. 

Use of the local form of the rn= parameter is out of 
the scope of the present specification. 

Tel URI npdi parameter as defined in IETF RFC 
4694 [93] is added only to the Request-URI. 


NOTE 1 : CC = Country Code of the network in which the O-IVIGCF is located. 

NOTE 2: If the address signals received in the ISUP Called Party Number contain a sending terminated signal 

(hexadecimal digit F), then this shall be discarded or if the PSTN XML is supported then the 

sendingCompletelndication shall be included. 



7.2.3.2.2A.1.2 



Concatenated Addressing Method 



Table 17b: Mapping ISUP to SIP Request-URI and To header field with Number Portability 

Concatenated Number Addressing Method 



lAM^ 


INVITE 


Called Party Number 


Request-URI and To Header Field 


Address Signal: 

Nature of address indicator: 

"Network routing number concatenated with 

called directory number" or 

"National (significant) number" as described 

in ITU-T 0.769.1 [92] 

(NOTE 2) 


The "telephone-subscriber" is populated from the Called Party 
Number as follows: 

Remove the prefix representing the Number Portability Routing Number 
or the prefix prior to the directory number (NOTES). 

Insert "+CC" before the Address signals (NOTE 1). 

The Tel URI rn= parameter is populated from the Called Party 
Number as follows and is added only to the Request-URI: 

Use all address digits contained within the Called Party Number or 
remove the digits that follow the prefix representing the Number 
Portability Routing Number 

Insert "+CC" before the Address signals (NOTE 1 ) 

Use of the local form of the rn= parameter is out of the scope of the 
present specification. 

Tel URI npdi parameter as defined in IETF RFC 4694 [93] is added 
only to the Request-URI. 


NOTE 1 : CC = Country Code of the network in which the O-IVIGCF is located. 

NOTE 2: If the address signals received in the ISUP Called Party Number contain a sending terminated signal 

(hexadecimal digit F), then this shall be discarded or if the PSTN XML is supported then the 

sendingCompletelndication shall be included. 
NOTE 3: Based on national policy the whole Number Portability Routing number includes the Called Party Number 

and a prefix. In such cases only the Prefix has to be removed. Normally the Nature of address indicator 

indicates if the Number Portability Routing Number contains a Called Party Number and a prefix. 
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7.2.3.2.2A.1.3 



Separate Network Routing Number Addressing Metinod 



Table 17c: Mapping ISUP to SIP Request-URI and To header field with Number Portability Separate 

Network Routing Number Addressing Method 



lAM^ 


INVITE 


Network Routing Number 


Called Party Number 


Request-URI and To Header Field 


Address Signal: 

Nature of address indicator: 

"Network routing number in national 
(significant) number format" or 
"Network routing number in network 
specific number format" as 
described in ITU-T Q.769.1 [92] 
(NOTE 2) 


Address Signal: 

Nature of address indicator: 

"National (significant) number". 


The "telephone-subscriber" is populated 
from the Called Party Number as follows: 

Insert "+CC" before the Address signals 
(N0TE1) 

The Tel URI rn= parameter is populated 
from the Network Routing Number as 
follows and is added only to the Request- 
URI: 

Insert "+CC" before the Address signals 
(N0TE1) 

Use of the local form of the rn= parameter is 
out of the scope of the present specification. 

Tel URI npdi parameter as defined in IETF 
RFC 4694 [93] is added only to the 
Request-URI. 


NOTE 1 : CC = Country Code of the network in which the 0-IVIGCF is located. 

NOTE 2: If the address signals received in the ISUP Called Party Number contain a sending terminated signal 

(hexadecimal digit F), then this shall be discarded or if the PSTN XML is supported then the 

sendingCompletelndication shall be included. 



7.2.3.2.2B Coding of the INVITE for Carrier Routeing 

This subclause describes optional coding procedures for carrier-based routeing. 

7.2.3.2.2B.1 Mapping of "cic" in REQUEST URI Header 

The procedures followed in subclause 7.2.3.2.2.1 apply with the following addition. 

If the Transit Network Selection parameter, defined according to ITU-T Q.761 [4], is included in the lAM message the 
O-MGCF, based on network configuration, may send the transit network selection information to the SIP network. In 
such a case the "cic=" parameter as defined in IETF RFC 4694 [93] is included in the SIP-Request URI and configured 
according to the table below. 

Table 17d: Mapping of ISUP "Transit Network Selection" (TNS) to SIP "Carrier Identification Code" 

(CIC) 



ISUP parameter/field 


Value 


SIP Component 


Value 


Transit Network Selection 


Digits 


Carrier id code in Userinfo of Request URI 


"cic=carrier ID code" as defined in 
IETF RFC 4694 [93] 



7.2.3.2.2B.2 Void 



7.2.3.2.2C 



Coding of INVITE with instance-id in form of IMEI URN 



An Emergency Access Transfer Function (FATE) that provides IMS-based mechanisms for enabling service continuity 
of IMS emergency sessions is described in 3GPP TS 23.237 [118]. A correlation of the call legs at the FATE is based 
on the equipment identifier. 

A Mobile Equipment Identifier (MEI) parameter of the Mobile Service Transport (MST) Application Transport 
Parameter is defined in 3GPP TS 29.205 [14]. 

An instance-id is a SIP Contact header field parameter defined in IETF RFC 5626 [119]. When an IMEI is available, 
the instance-id shall take the form of an International Mobile station Equipment Identity (IMEI) URN as specified in 
IETF draft-montemurro-gsma-imei-urn [120]. 
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When an O-MGCF receives the Mobile Service Transport (MST) Application Transport Parameter containing the 
Mobile Equipment Identifier (MEI) parameter within the lAM the O-MGCF shall perform the mapping to the 
"+sip.instance" Contact header field parameter according to table 7.2.3.2.2C.1. 

Table 7.2.3.2.2C.1 : Mapping of ISUP/BICC to SIP 



-» lAM 


^ INVITE 1 


ISUP Parameter 


Value 


SIP Component 


Value 


MST Application 
Transport Parameter 


IVIobile Equipment Identifier: 
IMEI 


Contact header 
containing "+sip. instance" 
parameter in the form of 
IMEI URN 


gmsa urn set to "imel" namespace 
NOTE 1 
NOTE 2 


Mobile Equipment Identifier: 
IMEISV 


NOTE 1 : The gsma-specifier "imel" Is generated as: 
urn:gsma:innei:tac-snr-spare 
where 

"tac" represents 8 digits type allocation code (TAG), "snr" represents 4 digits serial number (SNR), 
and "spare" represents spare decimal digit as specified in 3GPP TS 23.003 [74]. 
NOTE 2: The Software Version Number is not interworked and thus the "svn" parameter is not included within the 
gsma urn. 



7.2.3.2.3 



Receipt of CONTINUITY 



This subclause only applies if the O-MGCF has sent the INVITE request without waiting for an outstanding COT 

message (see subclause 7.2.3.2.1). 



O-MGCF 



COT(success) 



SDP indicating 
pre-conditions 
met 



Figure 14a: Receipt of COT (success) 

When the requested local preconditions (if any) have been met and if possible outstanding continuity procedures have 
successfully been completed (COT with the Continuity Indicators parameter set to "continuity check successful" is 
received), a SDP offer (e.g. a SIP UPDATE request, as defined in IETF RFC 33 11 [55]) shall be sent for each early SIP 
dialogue for which the received provisional response indicated support of preconditions confirming that all the required 
local preconditions have been met. If the O-MGCF previously offered inactive media stream it shall set the media 
stream to active mode. 

NOTE: This procedure applies regardless of whether the early SIP dialog existed prior to the preconditions being 
fulfilled or is subsequently created. 



7.2.3.2.4 



Sending of ACM and awaiting answer indication 



If the Address Complete Message (ACM) has not yet been sent, the following cases are possible trigger conditions that 
shall lead to the sending the address complete message (ACM): 

the detection of end of address signalling by the expiry of Timer T i/wi or. 
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0-MGCF 



lAM 



SAM 



SAM 



~UT i/wi running 
T i/wi running 



ACM (no indication) 



_T i/wi elapses 
INVITE 



Figure 15: Sending of ACIUI T i/wi elapses 

the reception of the first 180 Ringing. An O-MGCF initiates the sending of an awaiting answer indication only if 
according to IETF RFC 5009 [89] backward early media is not authorized (the most recently received P-Early- 
Media header field is received does not authorize the backward early media or the P-Early-Media header field 
has not yet been received). 

O-MGCF 



ACM (Subscriber Free) 



Ring tone 



180 Ringing 



Figure 16: Sending of ACIVI (Receipt of first 180 Ringing and bacltward early media is not authorized) 

Based on local knowledge that the call is transited to a PSTN network, the O-MGCF may decide not to generate 
the awaiting answer indication when receiving the 180 Ringing message and backward early media is not 
authorized according to IETF RFC 5009 [89]. 

O-MGCF 



ACM 

(Subscriber Free) 


180 Ringing 
[P-Early-Media header: 
backward early media 
^authorized] 








Ring tone 







Figure 16a: Sending of ACM (Receipt of first 180 Ringing and backward early media is authorized) 

the reception of the first 181 Call is Being Forwarded. 
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0-MGCF 



ACM 

(Call Diversion 
information) 



181 Call is Being 
Forwarded 



Figure 16b: Sending of ACIVI (Receipt of first 181 Call is Being Forwarded and backward early media 

is not authorized) 

0-MGCF 



ACM 

(Call Diversion 
information, OBCI: in- 
band info available) 



181 Call is Being 
Forwarded 
[P-Early-Media 
header: backward early 
media authorized] 



Audio 



Figure 16c: Sending of ACM (Receipt of first 181 Call is Being Forwarded that includes authorization 

of early media) 

At an O-MGCF once all the following sub-conditions have been met: { 1 } the reception of the first 183 Session 
Progress that includes a P-Early-Media header field authorizing backward early media, and {2} SDP 
preconditions are not used, or applicable SDP preconditions have been met. 

0-MGCF 



ACM 

(No indication, 
OBCI: in-band info 


183 Session Progress 
[P-Early-Media header: 
backward early media 
^authorized] 


available) 






Appropriate 
announcement 







Figure 16d: Sending of ACM (Receipt of first 183 Session Progress that includes authorization of 

early media) 

As a network option, reception of 183 containing a SIP reason header with an Q.850 Cause Value. 
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0-MGCF 



ACM( 
No indication 

Cause=xxx) 


183 Session Progress 
(Reason(Cause=xxx)) 











Figure 16e: Sending of ACIU! (Receipt of 183 Session Progress containing SIP Reason header) 

Ti/w 2 expires after the initial INVITE is sent. 

0-MGCF 



lAM 


INVITE 






^ ACM (no indication) 


k Ti/w 2 







Figure 17: Sending of ACIU! (Ti/W2 elapses) 

The sending of an awaiting answer indication is described in subclause 9.2.3.3. 

When a 180 (Ringing) response is received with the Alert-Info header field at an O-MGCF supporting capabilities 
associated with the Alert-Info header field an O-MGCF may instruct the IM-MGW to play out early media available at 
the associated URL to the PSTN leg of the communication. 

If the O-MGCF receives a 18x response with a P-Early-Media header field that changes the authorization of early 
media, the O-MGCF terminates the sending of the awaiting answer indication if the header field authorizes backward 
early media, and initiates the sending of the awaiting answer indication if the header field removes authorization of 
backward early media and if the O-MGCF has received the 180 Ringing response. 



7.2.3.2.5 



Coding of the ACM 



7.2.3.2.5.0 General 

The description of the following ISDN user part parameters can be found in ITU-T Recommendation Q.763 [4]. 

7.2.3.2.5.1 Backward call indicators 
bits AB Charge indicator Contributors 

1 charge 

bits DC Called party's status indicator 

01 subscriber free if the 180 Ringing has been received. 

00 no indication otherwise 

bits FE Called party's category indicator 

no indication 

bits HG End-to-end method indicator 

00 no end-to-end method available 

bit I Interworking indicator 
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1 interworking encountered 

As a network operator option, the value 1 = "no interworking encountered" is used for TMR = 64 kBit/s unrestricted 

NOTE: This avoids sending of a progress indicator with Progress information 1 "Call is not end-to-end 
ISDN; further call progress information may be available in-band", so the call will not be released for that 
reason by an ISDN terminal. 

bit J End-to-end information indicator 

no end-to-end information available 

bit K ISDN user part/BICC indicator 

ISDN user part not used all the way 

As a network operator option, the value K = 1 "ISDN user part/BICC used all the way" is used for TMR = 64 kBit/s 
unrestricted 

NOTE: This avoids sending of a progress indicator with progress information 1 "Call is not end-to-end 
ISDN; further call progress information may be available in-band", so the call will not be released for that 
reason by an ISDN terminal. 

bit L Holding indicator (national use) 

holding not requested 

bit M ISDN access indicator 

terminating access non-ISDN 

As a network operator option, the value M = 1 "terminating access ISDN" is used for TMR = 64 kBit/s unrestricted. 

NOTE: This avoids sending of a progress indicator with progress information 10 "Destination access is 
non-ISDN", so the call will not be released for that reason by an ISDN terminal. 

bit N Echo control device indicator 

1 incoming echo control device included, for speech calls, e.g., TMR is "3.1KHz audio". 

incoming echo control device not included, for known data calls, e.g., TMR "64 kBit/s unrestricted" 

or HLC "Facsimile Group 2/3". 

If the PSTN XML body is supported as a network option, the Backward Call indicators parameters derived as shown in 
table 7.2.3.2.5.1.1 shall take precedence over the above Backward Call indicators parameter setting. 
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Table 7.2.3.2.5.1.1 : Derivation of Backward Call Indicators from PSTN XIVIL body 



<-ACM 


<- 180 Ringing or 183 Session Progress 


Backward call indicators parameter 
Optional backward call indicators parameter 


PSTN XML body with Progress indicator with 

"Coding Standard" value "00 (ITU-T standardized 

coding)" and with "Progress Description" No (Value 

of PI) 


Backward call indicators parameter 

ISDN User Part indicator 

"ISDN User Part not used all the way" 


No. 1 

("Call is not end-to-end ISDN: further call progress 

information may be available in-band") 


Backward call indicators parameter 

ISDN User Part indicator 

"ISDN User Part used all the way" 

ISDN access indicator 

"Terminating access non-ISDN" 


No. 2 

("Destination address is non-ISDN") 


Backward call indicators parameter 

Interworking indicator 

"no interworking encountered" 

ISDN User Part indicator 

1 "ISDN User Part used all the way" 

ISDN access indicator 

1 "Terminating access ISDN" 


No. 7 

("Terminating user ISDN") 


Optional backward call indicators parameter 
In-band information indicator 
1 "in-band information or an appropriate pattern is 
now available 


No. 8 

("In-band information or an appropriate pattern is now 

available") 



7.2.3.2.5.2 



Optional Backward call indicators 



Bit A 1 "in-band information or an appropriate pattern is now available" shall be set if 183 Session Progress or 
181 Call is Being Forwarded response is received and according to IETF RFC 5009 [89] backward early 
media is authorized. 

Table 7a0.4: Sending criteria of Optional backward call indicators parameter 



<-ACM 


<- 183 Session Progress or 181 Call is 
Being Forwarded 


Optional backward call indicators parameter 
In-band information indicator 
in-band information or an appropriate pattern is now available 


P-Early-Media header authorizing backward 
early media 



7.2.3.2.5.3 



Access Transport Parameter, Transmission medium used parameter 



If the O-MGCF supports the PSTN XML body as a network option and if a PSTN XML body is received within the 180 
ringing or 183 session progress, the O-MGCF shall store the received PSTN XML elements, replacing any previously 
stored PSTN XML elements on that dialog. 

NOTE: Multiple 18x responses can be received, both within a single dialog and in multiple dialogs. The PSTN 
XML bodies are stored on a per-dialog basis to be mapped to the ATP/TMU parameters on receipt of the 
200 OK (see subclause 7.2.3.2.9.2). 

Table 7.2.3.2.5.3.1 : Void 



7.2.3.2.5.4 



Progress indicator 



If the O-MGCF supports the PSTN XML body as a network option and receives it in the 180 or 183, the O-MGCF shall 
store a "Progresslndicator" element from the PSTN XML body on a per dialog basis and shall add itionaly map it into a 
Progress Indicator in the ACM as shown in table 7.2.3.2.5.4.1. 
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Table 7.2.3.2.5.4.1 : Handling of the progress indicator 



<-ACM 


<-180/183 


Access transport parameter 


PSTN XML body with Progress indicator with "Coding 

Standard" value "00 (ITU-T standardized coding)" and with 

"Progress Description" No. (Value of PI) 


Progress indicator (NOTE) 


Progress indicator No. 1 / 2 


Progress indicator (NOTE) 


Progress indicator No. 8 


NOTE: The entire Progress Indicator, including the "Progress Description", "Coding Standard" and "Location" 
parameters shall be copied. 



Table 7.2.3.2.5.4.2: Void 



7.2.3.2.5.5 



Cause Value 



If the O-MGCF sends the ACM upon reception of a SIP 183 provisional response containing a SIP reason header with a 
Q.850 Cause value, the lO-MGCF may include the received Cause value within the ACM as a network option. The 
mapping of the Cause Indicators parameter to the Reason header as shown in table 8a shall be applied. IETF RFC 6432 
[115] describes the use of the Reason header field in responses. The Reason header field itself is described in IETF RFC 

3326 [116]. 



7.2.3.2.6 



Sending of the Call Progress message (CPG) 



7.2.3.2.6.0 



General 



If the Address Complete Message (ACM) has already been sent, the O-MGCF shall send the Call Progress message 
(CPG) in the following cases: 

Upon receipt of the SIP 180 Ringing provisional response. An O-MGCF should initiate the sending of an 
awaiting answer indication only if according to IETF RFC 5009 [89] backward early media is not authorized (the 
most recently received P-Early-Media header field does not authorize the backward early media or the P-Early- 
Media header field has not yet been received). 

O-MGCF 





CPG (Alerting) 




180 Ringing 










Ring tone 











Figure 18: Sending of CPG(Alerting) (Receipt of 180 Ringing response and backward early media is 

not authorized) 

O-MGCF 



CPG 


180 Ringing 
[P-Early-Media header: 
backward early media 
authorized] 


(Alerting) 






Ring tone 







Figure 18a: Sending of CPG(Alerting) (Receipt of 180 Ringing response with authorization of early 

media) 
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Based on local knowledge that the call is transited to a PSTN network, the O-MGCF may decide not to generate 
the awaiting answer indication when receiving the 180 Ringing message and backward early media is not 
authorized according to IETF RFC 5009 [89]. 

At an O-MGCF upon receipt of a 183 Session Progress that includes the first P-Early-Media header field 
authorizing backward early media. 

O-MGCF 



CPG 

(In-band information 
available) 



183 Session Progress 
[P-Early-Media header: 
backward early media 
authorized] 



Appropriate 
announcement 



Figure 18b: Sending of CPG(in-band information available) 

Upon receipt of the 181 Call is Being Forwarded provisional response. 

O-MGCF 



181 Call is Being 
Forwarded 
[P-Early-Media header: 
backward early media 
authorized] 



CPG 

(Progress, OBCI: in- 
band info available) 



Audio 



Figure 18c: Sending of CPG(Progress) 

As a network option, reception of 183 containing a SIP reason header with a Q.850 Cause Value. 



O-MGCF 
CPG (in-band 

information available 

Cause=xxx) 



183 Session Progress 
(Reason (Cause=xxx)) 



Figure 18d: Sending of CPG (Receipt of 183 Session Progress containing SIP Reason header) 

If the O-MGCF receives a 18x response with P-Early-Media header field that changes the authorization of early media, 
the O-MGCF terminates the sending of the awaiting answer indication if the header authorizes backward early media 
and initiates the sending of the awaiting answer indication if the header removes authorization of backward early media 
and if the O-MGCF has received the 180 Ringing response. 



7.2.3.2.6.1 



Handling of the progress indicator 



If the O-MGCF supports the PSTN XML body as a network option and receives it in the 1 80 or 183, any 
"Progresslndicator" element in the PSTN XML body shall be stored on a per-dialog basis as well as mapped as shown 
in tables 7.2.3.2.6.1.1 and 7.2.3.2.6.1.3. 
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Table 7.2.3.2.6.1.1 : Mapping of progress indicator in PSTN XIUIL body into ATP 



^CPG 


<-180/183 


Access transport parameter 


PSTN XML body with Progress indicator X 


Progress indicator (NOTE 1 , NOTE 3) 


Progress indicator No. 1 / 2 


Progress indicator (NOTE 2, NOTE 3) 


Progress indicator No. 4 


Progress indicator No. 4 (NOTE 2, NOTE 4) 


Progress indicator No. 7 


NOTE 1 : Values 1 ("call is not end-to-end ISDN: further call progress information may be available in-band") or 2 

("destination address is non-ISDN") shall be sent if Value 4 ("Call has returned to the ISDN") has been sent 

since value 1 or 2 was previously sent or if no value 1 or 2 was previously sent. 
NOTE 2: Value 4 ("Call has returned to the ISDN") shall be sent if value 1 ("call is not end-to-end ISDN: further call 

progress information may be available in-band") or 2 ("destination address is non-ISDN") was sent previously 

and no value 4 has been signalled since. 
NOTE 3: The entire Progress Indicator, including the "Progress Description", "Coding Standard" and "Location" 

parameters shall be copied. 
NOTE 4: The Progress Indicator "Coding Standard" parameter shall be set to "00 (ITU-T standardized coding)". The 

default value for the Progress Indicator "Location" parameter is "0100 (Public Network serving remote user)". 



Table 7.2.3.2.6.1.2: Void 



Table 7.2.3.2.6.1.3: Mapping of progress indicator in PSTN XML body into Event Indicator 



<-CPG 


<-180/183 


Event indicator 


PSTN XML body with Progress indicator with 

"Coding Standard" value "00 (ITU-T standardized 

coding)" and with Progress Description" value No. X 


"In-band information or appropriate pattern is now 
available" 


No. 8 

"In-band information or appropriate pattern is now 

available" 



7.2.3.2.7 



Coding of the CPG 



7.2.3.2.7.0 General 

The description of the following ISDN user part parameters can be found in ITU-T Recommendation Q.763 [4]. 

7.2.3.2.7.1 Event information 
bits G-A Event indicator 

1 alerting if 180 Ringing response received 

10 progress, if 181 Call is Being Forwarded response received 

1 1 in-band information or an appropriate pattern is now available, if the received 183 Session 

Progress response and most recently received P-Early-Media header authorizes backward early 
media 

NOTE: In national networks other values of the Event indicator may be used. 

If the O-MGCF supports the PSTN XML body as a network option and receives in the 180 or 183 a "Progresslndicator" 
element in the PSTN XML body with a "Coding Standard" value "00 (ITU-T standardized coding)" and with Progress 
Description" value No. 8, instead of the mapping above, the O-MGCF shall map this "Progress Indicator" into the 
"Event Indicator" within the CPG as shown in table 7.2.3.2.6.1.3. 



7.2.3.2.7.2 



Access Transport Parameter 



If the O-MGCF supports the PSTN XML body as a network option and if a PSTN XML body is received within the 180 
ringing or 183 session progress, the O-MGCF shall store the contained information as described in subclause 
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7.2.3.2.5.3, and additionally shall map this "Progress Indicator" into the ATP within the CPG as shown in table 

7.2.3.2.6.1.1. 

NOTE: Multiple 18x responses can be received, both within a single dialog and in multiple dialogs. The PSTN 
XML bodies are stored on a per-dialog basis to be mapped to the ATP parameter on receipt of the 200 
OK (see subclause 7.2.3.2.9.2). 



7.2.3.2.7.3 



Void 



7.2.3.2.7.4 



Table 17h: Void 
Table 17j: Void 

Handling of Backward Call indicators 



The Backward Call indicator shall be derived as shown in section 7.2.3.2.5.1. The Backward Call Indicators parameter 
is optional in the CPG message and shall only be included if any indicators have changed from those previously sent. 



7.2.3.2.7.5 



Optional Backward call indicators 



Bit A 1 "in-band information or an appropriate pattern is now available" shall be set if 181 Call is Being 
Forwarded response is received and according to IETF RFC 5009 [89] the backward early media is 
authorized. 

Table 17k: Sending criteria of Optional backward call indicators parameter 



<-CPG 


<- 181 Call is Being Forwarded 


Optional backward call indicators parameter 
In-band information indicator 
in-band information or an appropriate pattern is 
now available 


P-Early-Media header authorizing backward early media 



7.2.3.2.7.6 



Cause Value 



If the O-MGCF sends the CPG upon reception of a SIP 183 provisional response containing a SIP reason header with a 
Q.850 Cause value, the O-MGCF may include the received Cause value within the ACM as a network option. The 
mapping of the Cause Indicators parameter to the Reason header as shown in table 8a shall be applied. IETF RFC 6432 
[115] describes the use of the Reason header field in responses. The Reason header field itself is described in IETF RFC 
3326 [116]. 



7.2.3.2.7a 



Receipt of 200 OK(INVITE) 



Upon receipt of the first 200 OK (INVITE), the O-MGCF shall send an Answer Message (ANM) or Connect message 
(CON) as described in subclauses 7.2.3.2.8 to 7.2.3.2.11. 

The O-MGCF shall not progress any further early dialogues to established dialogues. Therefore, upon the reception of a 
subsequent final 200 (OK) response for any further dialogue for an INVITE request (e.g., due to forking), the O-MGCF 
shall: 

1) acknowledge the response with an ACK request; and 

2) send a BYE request to this dialog in order to terminate it. 

7.2.3.2.7b Internal through connection of the bearer path 

The through connection procedure is described in subclause 9.2.3.3.7. 
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7.2.3.2.8 Sending of the Answer Message (ANM) 

Upon receipt of the first 200 OK (INVITE), if the Address Complete Message (ACM) has already been sent, the O- 
MGCF shall send the Answer Message (ANM) to the preceding exchange. 

NOTE: Through connection and the stop of awaiting answer indication are described in subclause 9.2.3.3 

0-MGCF 



ANM 
< 



200 OK (INVITE) 

< 



Figure 19: Sending of ANIV! 

7.2.3.2.9 Coding of the ANM 

7.2.3.2.9.1 Backwards Call Indicators 

If Backwards Call Indicators are included in the ANM, then the coding of these parameters shall be as described in 
subclause 7.2.3.2.5.1. The Backward Call Indicators parameter is optional in the ANM message and shall only be 
included if any indicators have changed from those previously sent. 

7.2.3.2.9.2 Access Transport Parameter 

If the O-MGCF supports the PSTN XML body as a network option and if a PSTN XML body is received within the 200 
OK(INVITE) or has been previously stored from a 18x message, the O-MGCF shall map the most recently received 
information for the established dialog (i.e. the dialog for which the first 200 OK has been received) into the ANM as 
shown in table 7.2.3.2.9.2.1 except Progress Indicator value No. 3 or No. 8. 
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Table 7.2.3.2.9.2.1 : Mapping of PSTN XML elements into ISUP Parameters 



^ ANM 


<- 200 OK / stored information 
from previous 18x 


ISUP Parameter 


Content 


PSTN XIML (NOTE 9) 


Access Transport Parameter 


Progress indicator (NOTE 5, NOTE 8) 


Progresslndicator with "Coding 
Standard" value "00 (ITU-T 
standardized coding)" and with 
"Progress Description" value No. 1 / 
2 


Progress indicator with "Progress 
Description" value No. 4 (NOTE 4, NOTE 6, 
NOTE 9) 


Progresslndicator with "Coding 
Standard" value "00 (ITU-T 
standardized coding)" and with 
"Progress Description" value No. 7 


Progress indicator (NOTE 6, NOTE 8) 


Progresslndicator with "Coding 
Standard" value "00 (ITU-T 
standardized coding)" and with 
"Progress Description" value No. 4 


Progress indicator (NOTE 7, NOTE 8) 


Progresslndicator with "Coding 
Standard" value "00 (ITU-T 
standardized coding)" and with 
"Progress Description" value No. 5 


High layer compatibility (NOTE 1) 


HighLayerCompatibility 


Bearer Capability 


BearerCapability (NOTE 2) 


Bearer Capability ("UDI-TA") 


BearerCapability ("UDI-TA") (NOTE 
3) 


NOTE 1 : This information element shall only be mapped if the 0-MGCF transfers media types listed in table 10b 

without transcoding. 
NOTE 2: Applicable if the 0-IVIGCF has not propagated UDI fallback signalling according to subclause 7.2.3.2.1 .5. 
NOTE 3: Applicable if the 0-IVIGCF has propagated UDI fallback signalling according to subclause 7.2.3.2.1 .5. Only 

the value "UDI-TA" within the PSTN XML BC shall be mapped. Other values within the PSTN XIVIL BC are 

mapped to TMU as described in subclause 7.2.3.2.9.3. 
NOTE 4: Progresslndicator No. 7 is not mapped into the ISUP ATP. However, it may be mapped into Pl=4. 
NOTE 5: Values 1 ("call is not end-to-end ISDN: further call progress information may be available in-band") or 2 

("destination address is non-ISDN") shall be sent if Value 4 ("Call has returned to the ISDN") has been 

sent since value 1 or 2 was previously sent or if no value 1 or 2 was previously sent. 
NOTE 6: Value 4 ("Call has returned to the ISDN") shall be sent if value 1 ("call is not end-to-end ISDN: further call 

progress information may be available in-band") or 2 ("destination address is non-ISDN") was sent 

previously and no value 4 has been signalled since. 
NOTE 7: This value indicates a bearer service change and is present with an associated BearerCapability and 

indicates that fallback has occurred (i.e. TMR and TIVIR Prime present in lAM and the destination ISDN 

user has accepted the BearerCapability equating to TMR Prime). 
NOTE 8: The entire Progress Indicator, including the "Progress Description", "Coding Standard" and "Location" 

parameters shall be copied. 
NOTE 9: The Progress Indicator "Coding Standard" parameter shall be set to "00 (ITU-T standardized coding)". The 

default value for the Progress Indicator "Location" parameter is "01 00 (Public Network serving remote 

user)". 



7.2.3.2.9.3 



Transmission Medium Used parameter (TMU) 



The procedures in the present subclause shall only apply if the O-MGCF supports the PSTN XML body, and has 
propagated UDI-TA fallback signalling according to subclause 7.2.3.2.1.5. 

If a Bearer Capability element within a PSTN XML body is received within the first 200 OK(INVITE) or has been 
previously stored from a 18x message relating to the now established dialog (i.e. the dialogue for which the first 200 
OK has been received), the O-MGCF shall map the most recently received information (if any) into a TMU within the 
ANM as shown in table 7.2.3.2.9.3.1. If the most recently received PSTN XML BearerCapabiHty is "UDI-TA", it shall 
be mapped into an ISUP Access Transport Parameter Bearer Capability (see subclause 7.2.3.2.9.2). 

NOTE: The TMU is only included if both the TMR and TMR Prime were received in the ISUP lAM and fallback 
has occurred. 
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Table 7.2.3.2.9.3.1 - Mapping to TMU parameter 



^ ANM 


^ 200 OK / stored information from previous 18x 


TMU 


PSTN XML BearerCapability 


TMU = "Speech" 


PSTN XML BearerCapability = "Speech" 


TMU="3.1 kHz audio" 


PSTN XML BearerCapability = "3.1 kHz audio" 


No mapping (fallbacl< has not occurred) 


PSTN XML BearerCapability = "UDI-TA" 


TMU = "3.1 l<Hz audio" 


PSTN XML BearerCapability not present 



7.2.3.2.10 



Sending of the Connect message (CON) 



Upon receipt of the first 200 OK (INVITE), if the Address Complete Message (ACM) has not yet been sent, the O- 
MGCF shall send the Connect message (CON) to the preceding exchange. 



0-MGCF 



CON 



200 OK (INVITE) 



Figure 20: Sending of CON 



7.2.3.2.11 



Coding of the CON 



7.2.3.2.11.0 General 

The description of the following ISDN user part parameters can be found in ITU-T Recommendation Q.763 [4]. 

7.2.3.2.1 1 .1 Backward call indicators 

The Called Party's status indicator (Bit DC) of BCI parameter is set to "no indication". The other BCI indicators shall be 
set as described in subclause 7.2.3.2.5.1 

7.2.3.2.1 1 .2 Access Transport Parameter 

The O-MGCF shall apply the same procedure as described for the ANM in subclause 7.2.3.2.9.2. 

7.2.3.2.1 1 .3 Transmission medium used parameter 

The O-MGCF shall apply the same procedure as described for the ANM in subclause 7.2.3.2.9.3. 

7.2.3.2.1 1 A Receipt of a relNVITE request 

When a relNVITE request is received from the network containing a Call-Info header field the MGCF may instruct the 
IM-MGW to send media available at the associated URL to the PSTN leg of the communication. 



7.2.3.2.12 



Receipt of Status Codes 4xx, 5xx or 6xx 



O-MGCF 



REL 



Status Code 
4xx, 5xx or 6xx 



Figure 21 : Receipt of Status codes 4xx, 5xx or 6xx 

If a Reason header as described in IETF RFC 6432 [115] is included in a 4xx, 5xx, 6xx response, then the Cause Value 
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of the Reason header shall be mapped to the ISUP Cause Value field in the ISUP REL message. The Reason header 
field itself is described in IETF RFC 3326 [116]. The mapping of the Reason header to the Cause Indicators parameter 
is shown in table 8a (see subclause 7.2.3.1.7). Otherwise coding of the Cause value field in the REL message is derived 
from the SIP Status code received according to table 18. The Cause Indicators Parameter Values are defined in ITU-T 
Recommendation Q.850 [38]. 

In all cases where SIP itself specifies additional SIP side behaviour related to the receipt of a particular INVITE 
response these procedures should be followed in preference to the immediate sending of a REL message to BICC/ISUP. 

If there are no SIP side procedures associated with this response, the REL shall be sent immediately. 

NOTE Depending upon the SIP side procedures applied at the O-MGCF it is possible that receipt of certain 

4xx/5xx/6xx responses to an INVITE may in some cases not result in any REL message being sent to the 
BICC/ISUP network. For example, if a 401 Unauthorized response is received and the O-MGCF 
successfully initiates a new INVITE containing the correct credentials, the call will proceed. 
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Table 18: 4xx/5xx/6xx Received on SIP side of 0-MGCF 



<-REL (cause value) 


<-4xx/5xx/6xx SIP Message 


Cause value No 1 1 1 (Protocol error, unspecified) 


400 Bad Request 


Cause value No 127 (Interworking, unspecified) 


401 Unauthorized 


Cause value No 127 (Interworking, unspecified) 


402 Payment Required 


Cause value No 79 (Service or option not implemented, unspecified) 


403 Forbidden 


Cause value No 1 (Unallocated (unassigned) number) 


404 Not Found 


Cause value No 127 (Interworking, unspecified) 


405 Method Not Allowed 


Cause value No 127 (Interworking, unspecified) 


406 Not Acceptable 


Cause value No 127 (Interworking, unspecified) 


407 Proxy authentication required 


Cause value No 102 (Recovery on timer expiry) 


408 Request Timeout 


Cause value No 22 (Number changed) 


410 Gone 


Cause value No 127 (Interworking, unspecified) 


413 Request Entity too long 


Cause value No 111 (Protocol error, unspecified) 


414 Request-URI too long 


Cause value No 127 (Interworking, unspecified) 


415 Unsupported Media type 


Cause value No 111 (Protocol error, unspecified) 


416 Unsupported URI scheme 


Cause value No 79 (Service or option not implemented, unspecified) 


417 Unknown Resource-Priority 


Cause value No 111 (Protocol error, unspecified) 


420 Bad Extension 


Cause value No 111 (Protocol error, unspecified) 


421 Extension required 


Cause value No 31 (Normal, unspecified) 


422 Session Interval Too Small 


Cause value No 127 (Interworking, unspecified) 


423 Interval Too Brief 


Cause value No 24 (Call rejected due to ACR supplementary service) 


433 Anonymity Disallowed (NOTE 1) 


Cause value No 127 (Interworking, unspecified) 


440 Max-Breadth Exceeded 


Cause value No 20 (Subscriber absent) 


480 Temporarily Unavailable 


Cause value No 127 (Interworking, unspecified) 


481 Call/Transaction does not exist 


Cause value No 127 (Interworking, unspecified) 


482 Loop detected 


Cause value No 25 (Exchange routing error) 


483 Too many hops 


Cause value No 28 (Invalid number format (address incomplete)) 


484 Address Incomplete 


Cause value No 1 (Unallocated (unassigned) number) 


485 Ambiguous 


Cause value No 17 (User busy) 


486 Busy Here 


Cause value No 127 (Interworking, unspecified) or not interworked. (NOTE 2) 


487 Request terminated 


Cause value No 50 (Requested facility not subscribed) 


488 Not acceptable here 


Cause value No 127 (Interworking, unspecified) 


493 Undecipherable 


Cause value No 127 (Interworking, unspecified) 


500 Server Internal error 


Cause value No 79 (Service or option not implemented, unspecified) 


501 Not implemented 


Cause value No 27 (Destination out of order) 


502 Bad Gateway 


Cause value No 127 (Interworking, unspecified) 


503 Service Unavailable 


Cause value No 102 (Recovery on timer expiry) 


504 Server timeout 


Cause value No 127 (Interworking, unspecified) 


505 Version not supported 


Cause value No 127 (Interworking, unspecified) 


513 Message too large 


Cause value No 127 (Interworking, unspecified) 


580 Precondition failure 


Cause value No 17 (User busy) 


600 Busy Everywhere 


Cause value No 21 (Call rejected) 


603 Decline 


Cause value No 2 (No route to specified transit network) 


604 Does not exist anywhere 


Cause value No 88 (Incompatible destination) 


606 Not Acceptable 


NOTE 1 : Anonymity Disallowed, IETF RFC 5079 [77] refers. 

NOTE 2: No interworking if the 0-MGCF previously issued a CANCEL request for the INVITE. 

NOTE 3: The 4xx/5xx/6xx SIP responses that are not covered in this table are not interworked. 



If the O-MGCF supports the PSTN XML body as a network option and if a PSTN XML body is received within the 
4xx/5xx/6xx, the O-MGCF shall map the contained information into the Access Transport Parameter of the REL as 
shown in subclause 7.2.3.2.9.2. 

When a 4xx, 5xx or 6xx SIP response to an INVITE request is received from the network containing an Error-Info 
header field, the O-MGCF, supporting the capabilities associated with the Error-Info header field, may instruct the IM- 
MGW to play out media available at the associated URL towards PSTN. 



7.2.3.2.12.1 



Special handling of 404 Not Found and 484 Address Incomplete responses after 
sending of INVITE without determining the end of address signalling 



This subclause is only applicable when the network option of Sending of INVITE without determining the end of 
address signalling is being used (see subclause 7.2.3.2. La). 
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On receipt of a 404 Not Found or 484 Address Incomplete response while Ti/w2 is running, the O-MGCF shall start 
timer Ti/w3, if there are no other pending INVITE transactions for the corresponding call. 

At the receipt of a SAM, a SIP Ixx provisional response or a SIP 200 OK (INVITE), the O-MGCF shall stop Ti/w2 and 
Ti/w3. 

The O-MGCF shall send a REL message with Cause Value 28 towards the BICC/ISUP network if Ti/w3 expires. 

7.2.3 2.13 Receipt of a BYE 

O-MGCF 

BYE 

-4 — 

REL 



Figure 22: Receipt of BYE method 

If a Reason header field with Q.850 Cause Value is included in the BYE request, then the Cause Value shall be mapped 
to the ISUP Cause Value field in the ISUP REL as shown in table 8a (see subclause 7.2.3.1.7). Otherwise, the O-MGCF 
sends a REL message with Cause Code value 16 (Normal Call Clearing). 

If the O-MGCF supports the PSTN XML body as a network option and if a PSTN XML body is received within the 
BYE, the O-MGCF shall map the contained information into the Access Transport Parameter of the REL as shown in 
subclause 7.2.3.2.9.2. 

7.2.3.2.14 Receipt of the Release Message 

In the case that the REL message is received and a final response (i.e. 200 OK (INVITE)) has already been received the 
O-MGCF shall send a BYE request. If the final response (i.e. 200 OK (INVITE)) has not already been received the O- 
MGCF shall send a CANCEL method. 

A Reason header field containing the received (Q.850) Cause Value of the REL message shall be added to the 
CANCEL or BYE request. The mapping of the Cause Indicators parameter to the Reason header is shown in table 9a 
(see subclause 7.2.3. L8). 

If the O-MGCF supports the PSTN XML body as a network option, the O-MGCF shall map the contained information 
into a PSTN XML body within the BYE or CANCEL as shown in table 9aa. 

7.2.3.2.1 5 Receipt of RSC, GRS or CGB (H/W oriented) 

Upon receipt of a RSC, GRS or CGB (H/W oriented) message the following applies independently for each affected 
circuit: 

NOTE: For the RSC message, the circuit identified by the CIC is affected. 

For the GRS message, the affected circuits are identified by the CIC and the Range subfield of the Range 

and Status parameter. 

For the CGB message, the affected circuits are identified by the CIC and the Range and Status parameter. 

If a final response (i.e. 200 OK (INVITE) has already been received, the O-MGCF shall send a BYE method. If a final 
response (i.e. 200 OK (INVITE)) has not akeady been received, the O-MGCF shall send a CANCEL method. 

A Reason header field containing the (Q.850) Cause Value of the REL message generated by the ISUP procedures shall 
be added to the SIP message (BYE or CANCEL request) to be sent by the SIP side of the O-MGCF. 

Editor's Note: It is FFS whether to indicate the cause value for internal error in the network to the user. 

7.2.3.2.1 6 Autonomous Release at O-MGCF 

If the O-MGCF determines due to internal procedures that the call shall be released then the MGCF shall send 



ETSI 



3GPP TS 29.163 version 9.13.0 Release 9 



99 



ETSI TS 129 163 V9.13.0 (2013-04) 



- A BYE method if the ACK has been sent. 

- A CANCEL method before 200 OK (INVITE) has been received. 

NOTE: The MGCF shall send the ACK method before it sends the BYE, if 200 OK (INVITE) is received. 

A Reason header field containing the (Q.850) Cause Value of the REL message sent by the O-IWU shall be added to 
the SIP Message (BYE or CANCEL request) to be sent by the SIP side of the O-IWU. 

Editor's Note: It is EPS whether to indicate the cause value for internal error in the network to the user. 

Table 18a: Autonomous Release at 0-MGCF 



REL^ 
Cause parameter 


Trigger event 


^SIP 


As determined by BICC/ISUP 
procedure. 


COT received with the Continuity Indicators 

parameter set to "continuity cliecl< failed' (ISUP 

only) or the BICC/ISUP timer 78 expires. 


CANCEL or BYE according to 

the rules described in this 

subclause. 


REL with cause value 47 (resource 
unavailable, unspecified). 


Internal resource reservation unsuccessful 


As determined by SIP 
procedure 


As determined by BICC/ISUP 
procedure. 


BICC/ISUP procedures result in generation of 
autonomous REL on BICC/ISUP side. 


CANCEL or BYE according to 

the rules described in this 

subclause. 


Depending on the SIP release 
reason. 


SIP procedures result in a decision to release the 
call. 


As determined by SIP 
procedure. 



7.2.3.2.17 Special handling of 580 precondition failure received in response to either an 

INVITE or UPDATE 

A 580 Precondition failure response may be received as a response either to an INVITE or to an UPDATE request. 

7.2.3.2.1 7.1 580 Precondition failure response to an INVITE 

Release with cause code as indicated in table 17 is sent immediately to the BICC/ISUP network. 

7.2.3.2.1 7.2 580 Precondition failure response to an UPDATE within an early dialog 

A BYE request is sent for the early dialog within which the UPDATE was sent. 

If all the early dialogs that were generated from the INVITE request have answered the respective UPDATE request 
with 580 Precondition failure response then the O-MGCF shall send the Release message with Cause Code '127 
Interworking' to the ISUP network. 



7.2.3.2.18 



Sending of CANCEL 



O-MGCF 



COT (failure) 



CANCEL 



Figure 23: Receipt of COT (failure). 

CANCEL shall be sent if the Continuity message is received with the Continuity Indicators parameter set to "continuity 
check failed" or the ISUP (or BICC) timer T8 expires. 

A Reason header field containing the (Q.850) Cause Value 41 Temporary Failure shall be added to the CANCEL 
request to be sent by the SIP side of the O-MGCF. 
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7.2.3.2.19 Receipt of SIP redirect (3xx) response 

0-MGCF 



REL 

(Cause value 127) 
M 



SIP response 
code 3xx 



Figure 24: Receipt of SIP response code 3xx 

When receiving a SIP response with a response code 3xx, the defauh behaviour of the O-MGCF is to release the call 
with a cause code value 127 (Interworking unspecified). 

NOTE: The O-MGCF may also decide for example to redirect the call towards the URIs in the Contact header 
field of the response as an operator option, but such handling is outside of the scope of the present 
document. 

7.2.3.2.20 Sending of INFO for overlap signalling using the in-dialog method 

7.2.3.2.20.1 General 

SIP INFO request are used to carry additional digits when overlap signalling is sent using the in-dialog method as 
described in subclause 7.2.3.2. la.2, which is a network option. Subclause 7. 2. 3.2. la. 2 also describes when the O-MGCF 
sends a SIP INFO request. 

7.2.3.2.20.2 Encoding of the INFO 

Table 18b provides a summary of how the header fields within the outgoing INFO messages are populated when in- 
dialog SIP INFO requests are used for overlap dialling. 

Table 18b: Interworked contents of the INFO message 



SAM^ 


INFO^ 


Digits 


See Annex G 
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7.2.3.3 



Timers 



Table 19: Timers for interworking 



Symbol 


Time-out value 


Cause for initiation 


Normal termination 


At expiry 


Reference 


Ti/wl 


4 s to 6 s (default 
of 4 s) 


When last address 
message is received 
and the minimum 
number of digits 
required for routing the 
call have been 
received. 


At the receipt of fresh address 
information. 


Send INVITE, 
send the 
address 
complete 
message 


7.2.3.2.1 
7.2.3.2.4 
(N0TE1) 


Ti/w2 


4 s to 20 s 
(default of 4 s) 


When INVITE is sent 
unless the ACM has 
already been sent. 


On reception of 180 Ringing , 
or 183 Session Progress and 
P-Early-Media header 
authorizing backward early 
media, or 181 Call is Being 
Forwarded, or 404 Not Found 
or 484 Address Incomplete for 
an INVITE transaction for 
which Ti/w3 is running, or 200 
OK (INVITE). 


Send ACIVI (no 
indication) 


7.2.3.2.4 
7.2.3.2.1 
(NOTE 2) 


Ti/w3 


4-6 seconds 
(default of 4 
seconds) 


On receipt of 404 Not 
Found or 484 Address 
Incomplete if there are 
no other pending 
INVITE transactions for 
the corresponding call. 


At the receipt of SAIVI 


Send REL with 
Cause Value 
28 to the 
BICC/ISUP 
side. 


7.2.3.2.1A, 
7.2.3.2.12.1 

(NOTE 3) 


NOTE 1 : This timer is used when overlap signalling is received from BICC/ISUP network and converted to en-block 

signalling at the IVIGCF. 
NOTE 2: This timer is used to send an early ACIVI if a delay is encountered in receiving a response from the 

subsequent SIP network. 
NOTE 3: This timer is known as the "SIP dialog protection timer". This timer is only used where the 0-MGCF is 

configured to send INVITE before end of address signalling is determined. 



7.3 Interworking between CS networks supporting BICC and 
the IIVI CN subsystem 

The control plane between CS networks supporting BICC and the IM CN subsystem supporting SIP, where the 
underlying network is SS7 and IP respectively is as shown in figures 25, 26 and 27. 
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Figure 25: Control Plane interworking between CS networks supporting BICC over MTP3 and the IM 

CN subsystem 
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Figure 26: Control Plane interworking between CS networks supporting BICC over MTP3B over AAL5 

and the IM CN subsystem 
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Figure 27: Control Plane interworking between CS networks supporting BICC 
over STC and M3UA and the IM CN subsystem 

7.3.1 Services performed by network entities in tine control plane 

Services offered by the network entities in the control plane are as detailed in subclause 7.2.1. 

If ATM transport is applied between the SS7 Signalling function and the Signalling Gateway Function, they shall apply 
MTP3B (ITU-T Recommendation Q.2210 [46]) over SSCF (ITU-T Recommendation Q.2140 [45]) over SSCOP (ITU- 
T Recommendation Q.2110 [44]) over AAL5 (ITU-T Recommendation 1.363.5 [43]) as depicted in figure 26. 

If IP transport is applied between the SS7 Signalling function and the MGCF, they shall support and apply M3UA, 
SCTP and IP (either IPv4, see RFC 791 [16], or IPv6, see RFC 2460 [39]), as depicted in figure 27. 

7.3.2 Signalling interactions between network entities in the control plane 
7.3.2.1 Signalling between the SS7 signalling function and MGCF 

See subclause 7.2.2.1. 

7.3.2.1 .1 Signalling from MGCF to SS7 signalling function 

See subclause 7.2.2.1.1. 
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7.3.2.1 .2 Signalling from SS7 signalling function to MGCF 

See subclause 7.2.2.1.2. 

7.3.2.1 .3 Services offered by STC, SCTP and M3UA 

See subclause 7.2.2.1.3. 

7.3.2.1.3.1 Services offer by SCTP 
See subclause 7.2.2.1.3.1. 

7.3.2.1 .3.2 Services offered by M3UA 

See subclause 7.2.2.1.3.2. 

7.3.2.1.3.3 Services offered by STC 

STC provides the services for the transparent transfer of STC user information, e.g. BlCC, between STC users, i.e. the 
SS7 signalling function and the MGCF (see 3GPP TS 29.205 [14]). 

STC performs the functions of data transfer service availability reporting and congestion reporting to the STC user and 
User part availability control. See ITU-T Recommendation Q.2 150.1 [29]. 

7.3.2.2 Signalling between the MGCF and SIP signalling function 

See subclause 7.2.2.2. 

7.3.3 SIP-BICC protocol interworking 

7.3.3.1 Incoming call interworking from SIP to BlCC at l-MGCF 

7.3.3.1.1 Sending of lAM 

On reception of a SIP INVITE requesting an audio session, the I-MGCF shall send an lAM message. 

An I-MGCF shall support both incoming INVITE requests containing SIP preconditions and lOOrel extensions in the 
SIP Supported or Require header fields, and INVITE requests not containing these extensions, unless the Note below 
applies. 

NOTE: If the I-MGCF is deployed in an IMS network that by local configuration serves no user requiring 
preconditions, the MGCF may not support incoming requests requiring preconditions. 

The I-MGCF shall interwork forked INVITE requests with different request URIs. 

I-MGCF 



INVITE 

► 



lAM 



Figure 28: Receipt of INVITE 

The I-MGCF shall reject an INVITE request for a session only containing unsupported media types by sending a status 
code 488 "Not Acceptable Here". If audio media streams and non-audio media streams are contained in a single 
INVITE request, the non-audio media streams shall be rejected in the SDP answer, as detailed in IETF RFC 3264 [36]. 
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The I-MGCF shall include a To tag in the first backward non-100 provisional response, in order to establish an early 
dialog as described in IETF RFC 3261 [19]. 

7.3.3.1.2 Coding of lAM 

The description of the following ISDN user part parameters can be found in ITU-T Recommendation Q.763 [4]. 

7.3.3.1.2.1 Called party number 
See subclause 7.2.3.1.2.1. 

7.3.3.1 .2.2 Nature of connection indicators 
bits BA Satellite indicator 

no satellite circuit in the connection 
bits DC Continuity indicator (BICC) 

no COT to be expected, if the received SDP does not contain precondition information or 

indicates that all preconditions are fulfilled, and all local resource reservation is completed. 

1 COT to be expected, if the received SDP indicates that precondition is not fulfilled or any local 

resource reservation is not completed. 

bit E Echo control device indicator 

1 outgoing echo control device included 

7.3.3.1.2.3 Forward call indicators 
See subclause 7.2.3.1.2.3. 

7.3.3.1 .2.4 Calling party's category 

See subclause 7.2.3.1.2.4. 

7.3.3.1. 2. 4A Originating Line Information 

See subclause 7.2.3. 1.2.4A 

7.3.3.1.2.5 Transmission medium requirement 
See subclause 7.2.3.1.2.5. 

7.3.3.1.2.6 Calling party number 

See subclause 7.2.3.1.2.6. 

7.3.3.1.2.7 Generic number 

See subclause 7.2.3.1.2.7. 

7.3.3.1 .2.8 User service information 
See subclause 7.2.3.1.2.8. 

7.3.3.1 .2.9 Hop counter (National option) 
See subclause 7.2.3.1.2.9. 
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7.3.3.1.2.10 Location Number 

See subclause 7.2.3.1.2.11. 

7.3.3.1 .2A Coding of the I AM when Number Portability is supported 

See subclause 7.2.3.1.2A. 

7.3.3.1 .2B Coding of the JAM for Carrier Routeing 

See subclause 7.2.3.1.2B. 

7.3.3.1.3 Sending of COT 



I-MGCF 



SDP indicating 
preconditions met and/or 
active media 



COT 



Figure 29: Sending of COT 

If the lAM has already been sent, then the Continuity message shall be sent indicating "continuity check successful", 
when all of the following conditions have been met. 

When the requested remote preconditions (if any) in the IMS have been met. 

The media stream previously set to inactive mode is set to active (as specified in IETF RFC 4566 [56]). 

Local preconditions have been fulfilled. 

7.3.3.1 .3A Sending of SAM 

See subclause 7.2.3.1.3A. 

7.3.3.1 .4 Sending of 1 80 Ringing 

See subclause 7.2.3.1.4. 

7.3.3.1 .4A Sending of 1 83 Session Progress for early media scenarios 

See subclause 7.2.3.1.4A. 

7.3.3.1 .4B Sending of 1 81 Call is being forwarded 

See subclause 7.2.3.1.4B. 

7.3.3.1 .4C Sending of 1 83 Session Progress for overlap signalling using the in-dialog 

method 

See subclause 7.2.3.1.4C. 
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NOTE: If the network option of overlap signalling using the in-dialog method is applied at the I-MGCF in 

combination with the optional codec negotiation interworking with BICC in subclause B.2., in order to 
meet the requirement in subclause B.2.1 that the I-MGCF suspends the SDP answer procedure until it 
receives backward codec information from BICC, the 183 session progress response will not contain the 
SDP answer. 

7.3.3.1 .4D Sending of 1 83 Session Progress to carry ISUP Cause 

See subclause 7.2.3.1.4D. 

7.3.3.1 .5 Sending of the 200 OK (INVITE) 

See subclause 7.2.3.1.5. 

7.3.3.1 .6 Sending of the Release message (REL) 

See subclause 7.2.3.1.6. 

7.3.3.1.7 Coding of the REL 

See subclause 7.2.3.1.7. 

7.3.3.1 .8 Receipt of the Release Message 

See subclause 7.2.3.1.8. 

7.3.3.1 .9 Receipt of RSC, GRS or CGB (H/W oriented) 

See subclause 7.2.3.1.9. 

7.3.3.1 .9a Receipt of REFER 

See subclause 7.2.3.1.9a. 

7.3.3.1 .9b Autonomous Release at I-MGCF 

See subclause 7.2.3.1.10. 

7.3.3.1 .10 Internal through connection of the bearer path 

The through connection procedure is described in subclauses 9.2.2.1.5 and 9.2.2.2.5. 

7.3.3.1.11 Out of Band DTMF 

If a SIP UA sends DTMF tones to the IM-MGW, the IM-MGW may report this information via the Mn interface to the 
MGCF. The MGCF shall send to the BICC network the APM message with the following values for the different 
parameters: 

Action indicator in accordance with the requested DTMF transport function; 

Signal in accordance with which DTMF digit to send; 

Duration in accordance with the required duration of the DTMF digit. 

If the BICC network sends an APM message with DTMF signal, duration and action indicator to the MGCF, the MGCF 
may send this information to the IM-MGW via the Mn interface. The IM-MGW shall send the corresponding DTMF 
signal and duration information on the user plane of the IM CN subsystem according to RFC 4733 [105]. 

The interactions with the IM-MGW are shown in subclause 9.2.8. 
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7.3.3.2 Outgoing Call Interworking from BICC to SIP at 0-MGCF 

7.3.3.2.1 Sending of INVITE 

The following particularities apply for a BICC lAM received case, with regard to the already specified in subclause 
7.2.3.2.1. 

The O-MGCF should defer sending the INVITE request until the BICC bearer setup and any local resource reservation 
is completed. 

NOTE: If the O-MGCF sends the INVITE request before the BICC bearer setup and any local resource 

reservation is completed, the following considerations apply: If the receiving terminal is not supporting 
the SIP precondition, clipping may occur. Furthermore, if the MGCF sets the SDP "inactive" attribute in 
the initial INVITE request and the receiving terminal is not supporting the SIP precondition and the SIP 
UPDATE method, the interworking procedures within the present specification do not describe all 
necessary signalling interactions required to set up a call, in particular with respect to the sending of the 
re- INVITE that may also cause additional delay in the call setup. In addition, the interworking of the 
ringing indication might not be possible if the peer sends the ringing indication only as response to a re- 
INVITE. 

The BICC bearer setup is completed when one of the following conditions is met: 

The event Bearer Set-up indication - for the forward bearer set-up case where the incoming Connect Type is 
"notification not required", which indicate successful completion of bearer set-up, is received by the Incoming 
bearer set-up procedure (ITU-T Recommendation Q. 1902.4 [30] subclause 7.5); 

Bearer Set-up Connect indication for the backward call set-up case, which indicate successful completion of 
bearer set-up, is received by the Incoming bearer set-up procedure (ITU-T Recommendation Q. 1902.4 [30] 
subclause 7.5); 

BNC set-up success indication for cases using bearer control tunnelling which indicate successful completion of 
bearer set-up, is received by the Incoming bearer set-up procedure (ITU-T Recommendation Q. 1902.4 [30] 

subclause 7.5). 

7.3.3.2.1a Sending of INVITE without determining the end of address signalling 

See subclause 7.2.3.2.1a. 

7.3.3.2.2 Coding of the INVITE 

7.3.3.2.2.1 REQUEST URI Header 

See subclause 7.2.3.2.2.1 

7.3.3.2.2.2 SDP Media Description 

If the O-MGCF sends the INVITE request without waiting for the BICC bearer setup and any local resource reservation 
to complete (which is not recommended according to subclause 7.3.3.2.1), it shall indicate that SIP preconditions are 
not met when the initial INVITE request indicates support of the SIP preconditions. 

The SDP media description shall contain precondition information as per 3GPP TS 24.229 [9]. If the local preconditions 
are not met the O-MGCF should set the media stream to inactive mode (by including an attribute "a=inactive"). If the 
local configuration indicates that O-MGCF is deployed in the IMS network that serves users supporting SIP 
precondition mechanism, the attribute "a=inactive" may be omitted when the initial SDP offer indicates local 
preconditions are not met. If the initial SDP offer indicates local preconditions are fulfilled, the O-MGCF shall not set 
the media stream to inactive mode. 

The O-MGCF shall include the AMR codec transported according to IETF RFC 4867 [23] with the options listed in 
subclause 5. 1 . 1 of 3GPP TS 26.236 [32] in the SDP offer. Within the SDP offer, the O-MGCF should also provide SDP 
RR and RS bandwidth modifiers specified in IETF RFC 3556 [59] to disable RTCP, as detailed in subclause 7.4 of 
3GPPTS 26.236 [32]. 
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7.3.3.2.2.3 P-Asserted-ldentity and privacy header fields 
See subclause 7.2.3.2.2.3 

7.3.3.2.2. 3A "cpc" URI Parameter in P-Asserted-ldentity Header 

See subclause 7. 2.3.2. 2. 3A. 

7.3.3.2.2.3B "oli" URI Parameter in P-Asserted-ldentity Header 

See subclause 7. 2. 3. 2.2. 3B. 

7.3.3.2.2.4 Max Forwards header 

See subclause 7.2.3.2.2.4 

7.3.3.2.2.5 IMS Communication Service Identifier 

For speech and video calls, the O-MGCF shall insert an IMS Communication Service Identifier, indicating the IMS 
Multimedia Telephony Communication Service. 

The IMS Communication Service Identifier for the IMS Multimedia Telephony Communication Service is defined in 
3GPPTS 24.173 [88]. 

7.3.3.2.2.6 P-Access-Network-lnfo 

See subclause 7.2.3.2.2.9. 

7.3.3.2.2A Coding of the INVITE when number portability is supported 

See subclause 7. 2.3.2. 2A. 

7.3.3.2.2B Coding of the INVITE for Carrier Routeing 

See subclause 7.2.3.2.2B. 

7.3.3.2.2C Coding of INVITE with instance-id in form of IMEI URN 

See subclause 7.2.3.2.2C. 

7.3.3.2.3 Sending of UPDATE 

This subclause only applies if the O-MGCF sends the INVITE request before SIP preconditions are met (see subclause 
7.3.3.2.1). 

O-MGCF 
COT (success) 



-> 



UPDATE 

► 



Figure 30: Receipt of COT (success) 

The UPDATE request with a new SDP offer shall be sent for each early SIP dialogue for which the received provisional 
response indicated support of preconditions confirming that all the required local preconditions have been met when all 
the following conditions are met. 

1. A Continuity message, with the Continuity Indicators parameter set to "continuity check successful" shall be 
received. 
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2. The reservation of requested local resources has been completed. 

In addition, depending on which bearer set-up procedure used for the call one of the following condition shall be met: 

The event Bearer Set-up indication - for the forward bearer set-up case where the incoming Connect Type is 
"notification not required", which indicate successful completion of bearer set-up, is received by the Incoming 
bearer set-up procedure (ITU-T Recommendation Q. 1902.4 [30] subclause 7.5); 

Bearer Set-up Connect indication for the backward call set-up case, which indicate successful completion of 
bearer set-up, is received by the Incoming bearer set-up procedure (ITU-T Recommendation Q. 1902.4 [30] 
subclause 7.5); 

BNC set-up success indication for cases using bearer control tunnelling which indicate successful completion of 
bearer set-up, is received by the Incoming bearer set-up procedure, (ITU-T Recommendation Q. 1902.4 [30] 
subclause 7.5). 

If the O-MGCF previously offered inactive media stream it shall set the media stream to active mode. 

NOTE: This procedure applies regardless of whether the early SIP dialog existed prior to the preconditions being 
fulfilled or is subsequently created. 

7.3.3.2.4 Sending of ACM and Awaiting Answer indication 

See subclause 7.2.3.2.4 

The sending of an awaiting answer indication is described in subclause 9.2.3.1. and subclause 9.2.3.2. 

7.3.3.2.5 Coding of the ACM 

7.3.3.2.5.1 Backward call indicators 

See subclause 7.2.3.2.5.1 

7.3.3.2.6 Sending of the Call Progress message (CPG) 

See subclause 7.2.3.2.6. 

7.3.3.2.7 Coding of the CPG 

7.3.3.2.7.1 Event information 
See subclause 7.2.3.2.7.1. 

7.3.3.2.7.2 Optional Backward call indicators 

See subclause 7.2.3.2.7.5. 

7.3.3.2.7a Receipt of 200 OK (INVITE) 

See subclause 7.2.3.2.7a. 

7.3.3.2.7b Internal through connection of the bearer path 

The through connection procedure is described in subclauses 9.2.3.1.7 and 9.2.3.2.7. 

7.3.3.2.8 Sending of the Answer Message (ANM) 

See subclause 7.2.3.2.8. 
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7.3.3.2.9 Coding of the ANM 

See subclause 7.2.3.2.9. 

7.3.3.2.10 Sending of the Connect message (CON) 

See subclause 7.2.3.2.10. 

7.3.3.2.11 Coding of the CON 
See subclause 7.2.3.2.11. 

7.3.3.2.11.1 Void 

7.3.3.2.1 1 A Receipt of re-INVITE requests 

See subclause 7.2.3.2. 11 A. 

7.3.3.2.12 Receipt of Status Codes 4xx, 5xx or 6xx 

See subclause 7.2.3.2.12. 

7.3 3.2.13 Receipt of a BYE 

See subclause 7.2.3.2.13. 

7.3.3.2.14 Receipt of the Release Message 

See subclause 7.2.3.2.14. 

7.3.3.2.15 Receipt of RSC, GRS or CGB (H/W oriented) 

See subclause 7.2.3.2.15. 

7.3.3.2.16 Out of Band DTMF 

If a SIP UA sends DTMF tones to the IM-MGW, the IM-MGW may report this information via the Mn interface to the 
MGCF. The MGCP shall send to the BICC network the APM message with the following values for the different 
parameters: 

Action indicator in accordance with the requested DTMF transport function; 

Signal in accordance with which DTMF digit to send; 

Duration in accordance with the required duration of the DTMF digit. 

If the BICC network sends an APM message with DTMF signal, duration and action indicator to the MGCF, the MGCF 
may send this information to the IM-MGW via the Mn interface. The IM-MGW shall send the corresponding DTMF 
signal and duration information on the user plane of the IM CN subsystem according to 4733 [105]. 

The interaction with the IM-MGW is shown in subclause 9.2.8. 

7.3.3.2.17 Sending of CANCEL 

See subclause 7.2.3.2.18. 

7.3.3.2.18 Autonomous Release at 0-MGCF 

See subclause 7.2.3.2.16. 
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7.3.3.2.19 Special handling of 580 precondition failure received in response to either an 
INVITE or UPDATE 

See subclause 7.2.3.2.17. 

7.3.3.2.20 Receipt of SIP redirect (3xx) response 

See subclause 7.2.3.2.19. 

7.3.3.2.21 Sending of INFO for overlap signalling using the in-dialog method 

See subclause 7.2.3.2.20. 

7.3.3.3 Timers 

See subclause 7.2.3.3. 



7.4 Supplementary Services 



The following subclauses describe the MGCF behaviour related to supplementary services as defined in ITU-T 
Recommendations Q.730 to ITU-T Q.737 [42] when interworking with an IMS which does not use a Multimedia 
Telephony Application Server (MTAS) providing supplementary services according to 3GPP according to 3GPP TS 
24.173 [88]. The support of these supplementary services is optional. If the supplementary services are supported, the 
procedures described within this subclause shall be applied. 

7.4.1 Calling line identification presentation/restriction (CLIP/CLIR) 

The inter working between the Calling Party Number parameter and the P-Asserted-ID header and vice versa used for 
the CLIP-CLIR service is defined in the clauses 7.2.3.1.2.6 and 7.2.3.2.2.6. This inter working is essentially the same as 
for basic call and differs only in that if the CLIR service is invoked the "Address Presentation Restriction Indicator 
(APRI)" (in the case of ISUP to SIP calls) or the "priv value" of the "calling" Privacy header field (in the case of SIP to 
ISUP calls) is set to the appropriate "restriction/privacy" value. 

In the specific case of ISUP originated calls, use of the CLIP service additionally requires the ability to determine 
whether the number was network provided or provided by the access signalling system. Due to the possible SIP 
indication of the P-Asserted-Identity the Screening indicator is set to network provided as default. For the CLIP-CLIR 
service the mapping of the APRI from privacy header at the O-MGCF is described within table 16 in subclause 
7.2.3.2.2.6. 

At the O-MGCF the presentation restricted indication shall be mapped to the privacy header = "id" and "header". This is 
described in table 5 in subclause 7.2.3.1.2.6. 

7.4.2 Connected line presentation and restriction (COLP/COLR) 

7.4.2.0 General 

The COLP/COLR services are only to be interworked between trusted nodes - that is before passing any COLP/COLR 
information over the SIP-BICC/ISUP boundary the MGCF shall satisfy itself that the nodes on the BICC/ISUP side to 
which the information is to be passed are trusted. 

The procedure within subclause 7.5.2 for the generic number ("additional connected number") mapping shall apply. 

7.4.2.1 Incoming Call Interworking from SIP to BICC/ISUP at the l-MGCF 
7.4.2.1 .1 INVITE to lAM interworking (SIP to ISUP/BICC calls) 

In the case of SIP to ISUP/BICC calls the I-MGCF may invoke the COLP service as an operator option by setting the 
"Connected Line Identity Request indicator" field of the "Optional forward call indicators" parameter of the lAM to 
"requested". 
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NOTE: This implies that all outgoing calls will invoke the COLP service. 

7.4.2.1.2 ANM/CON to 200 OK (INVITE) 

Tables 20 and 21 specify the interworking required in the case when the COLP has been automatically requested on 
behalf of the originating SIP node. The table also indicates the inter workings required if the COLP service has been 
invoked and the called party has or has not invoked the COLR service. 

Table 20: Mapping to P-Asserted-ldentity and Privacy Header Fields 



SIP Component 


Setting 


P-Asserted-ldentity 


See table 21 


Privacy 


See table 22 



Table 21 : Mapping of connected number parameter to SIP P-Asserted-ldentity header fields 



BICC/ISUP 
parameter / field 


Value 


SIP component 


Value 


Connected Number 




P-Asserted-ldentity 
header field 




Nature of Address 
Indicator 


"national (significant) numbei" 


Tel URI or SIP URI 
(N0TE1) 


Add CC (of the country where 
the MGCF is located) to 
Connected PN address signals 
to construct E.164 number in 
URI. Prefix number with "+". 


"international numbei" 


Map complete Connected 
address signals to construct 
E.164 number in URI. Prefix 
number with "+". 


Address signal 


If NOA is "national (significant) 
number" Vr\er\ the format of the 
address signals is: 
NDC + SN 

If NOA is "international number" 
then the format of the address 
signals is: 
CC + NDC + SN 


Tel URI or SIP URI 
(N0TE1) 


CC+NDC-i-SN as E.164 number 
in URI. Prefix number with "+". 


NOTE 1 : A tel URI or a SIP URI with "user=phone" is used according to operator policy. 



Table 22: Mapping of BICC/ISUP APRIs into SIP privacy header fields 



BICC/ISUP 
parameter / field 


Value 


SIP component 


Value 


Connected Number 




Privacy header field 


priv-value 


APRI 

(See to determine 
which APRI to use 
for this mapping) 


"presentation restricted" 


Priv-value 


"id" 

("id" included only if the P- 
Asserted-ldentity header is 
included in the SIP INVITE) 


"presentation allowed" 


Priv-value 


omit Privacy header 

or Privacy header without "id" if 

other privacy service is needed 



7.4.2.2 Outgoing Call Interworking from BICC/ISUP to SIP at 0-MGCF 

7.4.2.2.1 lAM to INVITE interworking (ISUP to SIP calls) 

The O-MGCF determines that the COLP service has been requested by the calling party by parsing the "Optional 
Forward Call Indicators" field of the incoming lAM. If the "Connected Line Identity Request indicator" is set to 
"requested" then the BICC/ISUP to SIP interworking node shall ensure that any backwards "connected party" 
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information is interworked to the appropriate parameters of the ISUP ANM or CON message sent backwards to the 
calHng party as detailed within this subclause. 

The O-MGCF has to store the status of the "Connected Line Identity Request indicator". 

7.4.2.2.2 1 XX to ANM or CON interworking 

If the P-Asserted-Identity header field is included within a IXX SIP response, the identity shall be stored within the O- 
MGCF together with information about the SIP dialogue of the IXX SIP response and shall be included within the 
ANM or CON message if required by the procedures described in subclause 7.4.2.2.3. In accordance with ISUP 
procedures, a connected number shall not be included within the ACM message. The mapping of the of the P-Asserted- 
Identity and Privacy header fields is shown in tables 23 and 24. 

7.4.2.2.3 200 OK (INVITE) to ANM/CON interworking 

Tables 23 and 24 specify the interworking required in the case when the calling party has invoked the COLP service. 
The tables also indicate the interworking procedures required if the calling party has invoked the COLP service and the 
called party has or has not invoked the COLR service. 

If no P-Asserted-Identity header field is provided within the 200 OK (INVITE) message, the stored information 
previously received in the last provisional Ixx response of the same SIP dialogue shall be used. 

NOTE: Due to forking, other P-Asserted-Identities might have been received in different SIP dialogues. 

If the Calling Party has requested the COLP service (as indicated by the stored request status) but the 200 OK (INVITE) 
and previous IXX provisional responses do not include a P-Asserted-Identity header field, the O-MGCF shall set up a 
network provided Connected Number with an Address not Available indication. 

If the P-Asserted-Identity is available then the Connected number has to be setup with the screening indication network 
provided. The mapping of the P-Asserted-Identity and Privacy (if available) is shown in table 24. 
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Table 23: Connected number parameter mapping 



<- ANM/CON 


<- 200 OK INVITE 


Connected Number (Network Provided) 


P-Asserted-ID 


Address Presentation Restricted Indicator 


Privacy Value Field 



Table 24: Mapping of P-Asserted-ldentity and privacy headers to the ISUP/BICC connected number 

parameter 



SIP component 


Value 


BICC/ISUP parameter / field 


Value 


P-Asserted-ldentity 
header field (NOTE 1) 


E.164 number 


Connected Number 






Number incomplete indicator 


"Complete" 


Numbering Plan Indicator 


"ISDN/Telephony (E.164)" 


Nature of Address Indicator 


If CC encoded in the URI is equal to the 
CC of the country where MGCF is 
located AND the next BICC/ISUP node 
is located in the same country then 
set to "national (significant) number" 
else set to "international number" 


Address Presentation 
Restricted Indicator (APRI) 


Depends on priv-value in Privacy 
header. 


Screening indicator 


Network Provided 


Addr-spec 


"CC" "NDC" 
"SN" from the 
URI 


Address signal 


if NOA is "national (significant) number" 
then set to "NDC" + "SN". 
If NOA is "international number" 
then set to "CC"-h"NDC"+"SN". 


Privacy header field is 
not present 




APRI 


Presentation allowed 


Privacy header field 


priv-value 


APRI 


"Address Presentation Restricted 
Indicator" 


priv-value 


"header" 


APRI 


Presentation restricted 


"user" 


APRI 


Presentation restricted 


"none" 


APRI 


Presentation allowed 


"id" 


APRI 


Presentation restricted 


NOTE 1 : It is possible that a P-Asserted -Identity header field includes both a TEL URI and a SIP or SIPS URI. 
In this case, either the TEL URI or the SIP URI with user="phone" and a specific host portion, as 
selected by operator policy, may be used. 



7.4.3 Direct Dialling In (DDI) 

A direct dialling in call is a basic call and no additional treatment is required by the MGCF. 

7.4.4 Malicious call identification 

The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.731.7 [42] under the 
clause "Interactions with other networks". 

7.4.5 Subaddressing (SUB) 
7.4.5.1 General 

The ISDN Subaddress in ISUP is transported within the Access Transport Parameter. The Coding of the Subaddress 
parameter within the Access Transport Parameter is described within ETSI EN 300 403-1 [96]. The isdn-subaddress 
parameter carried within a tel or sip URI is defined within RFC 3966 [97]. The isdn-subaddress encoding type carried 
within a tel or sip URI is defined within RFC 4715 [108]. 
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7.4.5.2 Incoming Call Interworking from SIP to ISUP at l-MGCF 

The mapping in table 24ba of the isdn-subaddress parameter received within a tel or sip URI to the ISUP Access 
Transport Parameter encapsulating the Subaddress shall be applied. 

The mapping in table 24bb of the Subaddress received within an ANM Message containing the ISUP Access Transport 
Parameter to the isdn-subaddress of a tel or sip URI to be sent within a 200 OK (INVITE) shall be applied. 

Table 24ba: Mapping of the Subaddress received in an initial INVITE to the Subaddress sent in the 

lAM 



SIP Message INVITE 


ISUP Message lAM | 


Source SIP 

header field 

and component 


Source component value 


ISUP 

Parameter 

field 


Derived value of parameter field 


To header field 
including the 
isdn-subaddress 
(NOTE) 


"isub=" 1*uric 

"uric" 

containing the 
Subaddress 
digits 


isub-encoding not 
present 


Access 

Transport 

Parameter 


called party 
Subaddress 


Type of Subaddress = 
"NSAP" (000) 


"isub- 
encoding=nsap-ia5" 


"isub- 

encoding=nsap- 

bcd" 


Type of Subaddress = 
"NSAP" (000) 


"isub- 
encoding=nsap" 


Type of Subaddress = 
"NSAP" (000) 


"isub=" 1*uric ("uric" containing the 
Subaddress digits) and isub-encoding 
does not contain nsap value 


No mapping 


P-Asserted- 
Identity header 
Field 

including the 
isdn-subaddress 


";isub=" 1*uric 

"uric" 

containing the 
Subaddress 
digits 


isub-encoding not 
present 


Access 

Transport 

Parameter 


calling party 
Subaddress 


Type of Subaddress = 
"NSAP" (000) 


"isub- 
encoding=nsap-ia5" 


"isub- 

encoding=nsap- 

bcd" 


Type of Subaddress = 
"NSAP" (000) 


"isub- 
encoding=nsap" 


Type of Subaddress = 
"NSAP" (000) 


"isub=" 1*uric ("uric" containing the 
Subaddress digits) and isub-encoding 
does not contain nsap value 


No mapping 


NOTE: As an operator option, an isdn-subaddress within the Request-URI may also be mapped into the ISUP 
Access Transport parameter. 



Table 24bb: Mapping of the Subaddress received in an ANM to the Subaddress sent in the 200 OK 

(INVITE) 



ISUP Message ANM 


SIP Message 200 (OK) | 


ISUP Parameter field 


Source component value 


Source SIP header field 
and component 


Derived value of parameter 
field 


Access Transport 
Parameter 


connected party Subaddress 
and Type of Subaddress = 
"NSAP" (000) 


P-Asserted-ldentity 
including the isdn- 
subaddress 


";isub=" 1*uricand "isub- 
encoding=nsap-ia5" 
The Subaddress digits 
included into the "uric" shall be 
derived from the Access 
Transport Parameter 


connected party Subaddress 
and Type of Subaddress ^ 
"NSAP" (000) 


No mapping 



7.4.5.3 Outgoing Call Interworking from ISUP to SIP at 0-MGCF 

The mapping in table 24bc of the isdn-subaddress parameter received within a tel or sip URI to the ISUP Access 
Transport Parameter encapsulating the Subaddress shall be applied. 



£75/ 



3GPP TS 29.163 version 9.13.0 Release 9 



116 



ETSI TS 129 163 V9.13.0 (2013-04) 



The mapping in table 24bd of the Subaddress received within an ANM Message containing the ISUP Access Transport 
Parameter to the isdn-subaddress of a tel or sip URI to be sent within a 200 OK (INVITE) shall be applied. 

Table 24bc: Mapping of the Subaddress received in an lAM to the Subaddress sent in the INVITE 



ISUP lAM Message 


SIP INVITE Message | 


ISUP Parameter 
field 


Source component value 


Source SIP header 
field and component 


Derived value of parameter 
field 


Access Transport 
Parameter 


called party Subaddress and 
Type of Subaddress = "NSAP" 
(000) 


To header field 
including the isdn- 
subaddress, and, as an 
operator option. 
Request URI 


";isub=" ruric and "isub- 

encoding=nsap-ia5" 

The Subaddress digits included 

into the "uric" shall be derived 

from the Access Transport 

Parameter 


called party Subaddress and 
Type of Subaddress * "NSAP" 
(000) 


No mapping 


calling party Subaddress and 
Type of Subaddress = "NSAP" 
(000) 


P-Asserted-ldentity 
header field including 
the isdn-subaddress 


";isub=" ruric and "isub- 

encoding=nsap-ia5" 

The Subaddress digits included 

into the "uric" shall be derived 

from the Access Transport 

Parameter 


calling party Subaddress and 
Type of Subaddress * "NSAP" 
(000) 


No mapping 



Table 24bd: Mapping of the Subaddress received in a 200OK to the Subaddress sent in the ANM 



SIP Message 200 (OK) 


ISUP Message ANM | 


Source SIP 

header field 

and component 


Source component value 


ISUP 

Parameter 

field 


Derived value of parameter field 


P-Asserted- 
Identity header 
Field 

including the 
isdn-subaddress 


"isub=" ruric 

"uric" 

containing the 
Subaddress 
digits 


isub-encoding not 
present 


Access 

Transport 

Parameter 


connected 

party 

Subaddress 


Type of Subaddress = 
"NSAP" (000) 


"isub- 
encoding=nsap-ia5" 


"isub- 

encoding=nsap- 

bcd" 


Type of Subaddress = 
"NSAP" (000) 


"isub- 
encoding=nsap" 


Type of Subaddress = 
"NSAP" (000) 


"isub=" 1*uric ("uric" containing the 
Subaddress digits) and isub-encoding 
does not contain nsap value 


No mapping 



7.4.6 Call Forwarding Busy (CFB)/ Call Forwarding No Reply (CFNR) / 
Call Forwarding Unconditional (CFU) / Call Deflection (CD) 



7.4.6.1 



General 



A MGCF within an IMS network applying the Communication Diversion service uses the procedures defined in 
subclause 7.5.4. 

This subclause describes additional interworking of call forwarding service information between a PSTN/PLMN 
network and an IMS network. This can also be used when interworking between SIP networks (e.g., IMS network 
interworking with enterprise networks making use of the History-Info header with an escaped Reason header as 
described in IETF RFC 4244 [91]). The procedures support the interworking of the diversion reason within the History- 
Info header using an escaped Reason header defined by IETF RFC 3326 [116] as described in IETF RFC 4244 [91] and 
also support the diversion cause using the cause-parm as described by IETF RFC 4458 [113]. 
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If the MGCF is supporting the interworking of Call Forwarding and also applying the Communication Diversion 
services as defined by 3GPP TS 24.604 [60], it uses both IETF RFC 4244 [91] and IETF RFC 4458 [113] to signal the 
diversion reason. An IMS network supporting the interworking of Call Forwarding and not applying the IMS 
Communication Diversion supplementary service according to 3GPP TS 24.604 [60] uses IETF RFC 4244 [91] and can 
also use IETF RFC 4458 [113] based on network option. 

When interworking the SIP History-Info header to ISUP, and both the diversion reason based on IETF RFC 4244 [91] 
and IETF RFC 4458 [113] are present for the same diversion instance, the MGCF should use the cause-parm URI 
parameter per IETF RFC 4458 [113] for deriving the ISUP. When the cause-parm URI parameter per IETF RFC 4458 
[113] is used, the corresponding interworking as described in subclause 7.5.4 shall be applied for that diversion 
instance. Otherwise, the interworking as defined in the present subclause should be applied. 

When interworking from ISUP to the History-Info header, to signal the diversion reason the MGCF should use the 
escaped Reason header from IETF RFC 4244 [91] and apply the interworking procedures in the present subclause. The 
MGCF should also apply the interworking procedures described in subclause 7.5.4 to use the cause-parm from IETF 
RFC 4458 [113] to signal the diversion reason. 

In the event that the interworking procedures described in this subclause as well as the interworking procedures in 
subclause 7.5.4 are not applied, the actions of the MGCF at the ISUP/BICC side as described in ITU-T 
Recommendation Q. 732. 2-5 [42] under the clause "Interactions with networks not providing any call diversion 
information" may be applied as a network option. 



7.4.6.2 



Interworking at the 0-MGCF 



7.4.6.2.1 



General 



This subclause describes the optional mapping of Call Forwarding information at the O-MGCF to the protocol-cause 
specified in IETF RFC 3326 [1 16]. 



7.4.6.2.2 



Interworking SIP to ISUP 



Table 7.4.6.2.2.1 : Mapping of SIP messages to ISUP messages 



<-Message sent to ISUP 


^-Message Received from SIP 




ACM indicating call forwarding 


181 (Call Is Being Forwarded) response 


See table 7.4.6.2.2.6 


CPG indicating call forwarding (see NOTE) 


181 (Call Is Being Forwarded) response 


See table 7.4.6.2.2.7 


ACIVI indicating ringing 


180 (Ringing) response 


See table 7.4.6.2.2.8 


CPG indicating Alerting (see NOTE) 


180 (Ringing) response 


See table 7.4.6.2.2.9 


ANM 


200 (OK) response 


See table 7.4.6.2.2.10 


CON 


200 (OK) response (Neither a 181 (Call Is 
Being Forwarded) response nor a 180 
(Ringing) response was received) 


See table 7.4.6.2.2.10 


NOTE: A CPG will be sent if an ACM was already sent. 
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Table 7.4.6.2.2.2: Mapping of History-Info hieader field to ISUP Redirection number 



Source SIP header field 
and component 


Source 

Component 

value 


Redirection number 


Derived value of parameter field 


hi-targeted-to-uri of the 
History-Info header 
following the last History- 
Info entry field entry 
containing a Reason 
header as defined in IETF 
RFC 4244 [91] with cause 
value as listed in table 
7.4.6.2.2.4 

appropriate global number 
portion of the hi-targeted-to- 
uri, assumed to be in form 
"+" CC -1- NDC -1- 
SN.(NOTE) 


CC 


Nature of address indicator 


If CC is equal to the country code of the 
country where 0-MGCF is located AND 
the next ISUP node is located in the 
same country, then set to "national 
(significant) numbei" else set to 
"international numbei". 


CC, NDC, SN 


Address signals 


If NOA is "national (significant) number" 

then set to 

NDC-i-SN. 

If NOA is "international numbei" 

then set to CC -^ NDC -1- SN. 


NOTE: If it is SIP URI and doesn"t contain " user=phone" , mapping to redirection number is impossible, 

therefore no need to generate Redirection number and Redirection number restriction indicator (per 
table 7.4.6.2.2.3), Notification subscription options can"t be set as "presentation allowed with redirection 
number". 



Table 7.4.6.2.2.3: IVIapping of IHistory-lnfo hieader field to ISUP Redirection number restriction 



Source SIP header field 
and component 


Source 

Component 

value 


Redirection number 
restriction 


Derived value of parameter field 


Privacy header field, or 
priv-value component of the 
hi-entry following the last 
History-Info entry 
containing a Reason 
header as defined in IETF 
RFC 4244 [91] with cause 
value as listed in table 
7.4.6.2.2.4 


"history or 
"session" or 
"headei" 


Presentation restricted 
indicator 


"Presentation restricted' 


Privacy 
header field 
absent or 
"none" 


"Presentation allowed' or absent 
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Table 7.4.6.2.2.4: Mapping of hi-targeted-to-uri to ISUP Call Diversion Information 



Source SIP header field 
and component 


Source Component 
value 


Call Diversion 
Information 


Derived value of parameter field 


Privacy header field, 
priv-value component 


"history or "session" or 
"tieadei" 


Notification 

subscription 

options 


If the priv-value "history or "session" or 
"header is set for the History-Info 
header field or to the hist-info element 
entries concerning the redirecting (see 
table 7.4.6.3.2.2) and diverted to uri 
(see table 7.4.6.2.2.2) then 
"presentation notailowed' shall be set 
If the priv-value "history" or "session" or 
"headei" is set only to the hist-info 
element concerning the diverted-to uri 
then "presentation aiiowed without 
redirection number" shall be set. 


Privacy header field 

absent 

or "none" 


Presentation aiiowed with redirection 
number 


hi-targeted-to-uri; Reason 
header as defined in IETF 
RFC 4244 [91] with cause 
parameter 


Cause parameter 
value 


Call diversion 
information 


Redirecting Reason 


302 


Defiection immediate response 


486 


User busy 


408 


No repiy 


503 


Mobiie subscriber not reachable 


all other cause values 


Unknown 



Table 7.4.6.2.2.5: Void 

Table 7.4.6.2.2.6: Mapping of 181 (Call Is Being Forwarded) -> ACM when ACM was not previously 

sent 



Source SIP header field 
and component 


Source Component 
value 


ISUP Parameter 


Derived value of parameter 
field 


181 (Call Is Being 
Forwarded) 




ACM 








Generic notification 
indicators 


Call is diverting 


History-Info header field 


See table 7.4.6.2.2.2 


Redirection number 


See table 7.4.6.2.2.2 


Priv-value 


See table 7.4.6.2.2.3 


Redirection number 
restriction 


See table 7.4.6.2.2.3 


Priv-value 


See table 7.4.6.2.2.4 


Call diversion information 
Notification subscription 
options 


See table 7.4.6.2.2.4 


hi-targeted-to-uri; Reason 
header as defined in IETF 
RFC 4244 [91] with cause 
parameter 


See table 7.4.6.2.2.4 


Call diversion information 


Redirecting Reason 
See table 7.4.6.2.2.4 
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Table 7.4.6.2.2.7: Mapping of 181 (Call Is Being Forwarded)-^ CPG if ACIVI was already sent 



Source SIP header field 
and component 


Source Component 
value 


ISUP Parameter 


Derived value of parameter 
field 


181 (Call Is Being 
Forwarded) response 




CPG 








Generic notification 
indicators 


Cali is diverting 


hi-targeted-to-uri; Reason 
header as defined in IETF 
RFC 4244 [91] with cause 
parameter 


486 


Event indicator 


CFB (national use) 


408 (see NOTE) 


CFNR (national use) 


all other values, or if 
appropriate national 
use value CFB, CFNR 
or CFU is not used in a 
network, or if no hi- 
targeted-to-uri cause- 
param URI parameter 
is contained in the SIP 
181. 


Progress 


History-Info header field 


See table 7.4.6.2.2.2 


Redirection number 


See table 7.4.6.2.2.2 


Priv-value 


See table 7.4.6.2.2.3 


Redirection number 
restriction 


See table 7.4.6.2.2.3 


Priv-value 


See table 7.4.6.2.2.4 


Call diversion information 
Notification subscription 
options 


See table 7.4.6.2.2.4 


hi-targeted-to-uri; Reason 
header as defined in IETF 
RFC 4244 [91] with cause 
parameter 


See table 7.4.6.2.2.4 


Call diversion information 
Redirecting Reason 


See table 7.4.6.2.2.4 


NOTE: This appears in the cases of CFNR. 



Table 7.4.6.2.2.8: Mapping of 180 (Ringing) ^ ACM when ACM was not previously sent 



Source SIP header field 
and component 


Source Component 
value 


ISUP Parameter 


Derived value of parameter 
field 


180 (Ringing) response 




ACM 




History-Info header field 


If hi-targeted-to-uri of at 
least one History-Info 
hi-entry contains a 
Reason header as 
defined in IETF RFC 
4244 [91]. 


Generic notification 
indicators 


Call is diverting 


History-Info header field 


See table 7.4.6.2.2.2 


Redirection number (NOTE) 


See table 7.4.6.2.2.2 


Priv-value 


See table 7.4.6.2.2.3 


Redirection number 
restriction (NOTE) 


See table 7.4.6.2.2.3 


Priv-value 


See table 7.4.6.2.2.4 


Call diversion information 
Notification subscription 
options (NOTE) 


See table 7.4.6.2.2.4 


hi-targeted-to-uri; Reason 
header as defined in IETF 
RFC 4244 [91] with cause 
parameter 


See table 7.4.6.2.2.4 


Call diversion information 
Redirecting Reason (NOTE) 


See table 7.4.6.2.2.4 


NOTE: Parameter shall only be supplied if hi-targeted-to-uri contains a Reason header, as defined in IETF 
RFC 4244 [91] with cause value as listed in table 7.4.6.2.2.4. 



The mapping described within table 7.4.6.2.2.1 can only appear if the communication has already undergone a Call 
Forwarding in the ISDN/PSTN and the 180 is the first provisional response sent in backward direction. 

The IWU can indicate the call diversion in the mapping of 1 80 (Ringing) to CPG in fact if the response before was 
a 181 (Call is being forwarded). 



£75/ 



3GPP TS 29.163 version 9.13.0 Release 9 



121 



ETSI TS 129 163 V9.13.0 (2013-04) 



Table 7.4.6.2.2.9: Mapping of 180 (Ringing) ^ CPG if ACIVI was already sent 



Source SIP header field 
and component 


Source Component 
value 


ISUP Parameter 


Derived value of parameter 
field 


180 (Ringing) response 




CPG 








Generic notification 
indicators 


Cali is diverting 


History-Info header field 




Event indicator 


ALERTING 


History-Info header field 


See table 7.4.6.2.2.2 


Redirection number (NOTE) 


See table 7.4.6.2.2.2 


Priv-value 


See table 7.4.6.2.2.3 


Redirection number 
restriction (NOTE) 


See table 7.4.6.2.2.3 


Priv-value 


See table 7.4.6.2.2.4 


Call diversion information 
Notification subscription 
options (note; 


See table 7.4.6.2.2.4 


hi-targeted-to-uri; Reason 
header as defined in IETF 
RFC 4244 [91] with cause 
parameter 


See table 7.4.6.2.2.4 


Call diversion information 
Redirecting Reason (NOTE) 


See table 7.4.6.2.2.4 


NOTE: Parameter shall only be supplied if hi-targeted-to-uri contains a Reason header, as defined in IETF 
RFC 4244 [91] with cause value as listed in table 7.4.6.2.2.4. 



The mapping in table 7.4.6.2.2.9 appears when a 181 previously was mapped to an ACM. Therefore the state machine 
of the MGCF knows that a CDIV is in Progress. 

Table 7.4.6.2.2.10: Mapping of 200 (OK) response 



Source SIP header field 
and component 


Source Component 
value 


ISUP Parameter 


Derived value of parameter 
field 


200 (OK) response 




ANM/CON 




History-Info header field 


See table 7.4.6.2.2.2 


Redirection number 


See table 7.4.6.2.2.2 


Priv-value 


See table 7.4.6.2.2.3 


Redirection number 
restriction 


See table 7.4.6.2.2.3 



7.4.6.2.3 



Interworking ISUP to SIP 



For the interworking of 180 (Ringing) response and 200 (OK) response to the regarding ISUP messages and parameters 
no additional procedures beyond the basic call procedures are needed. 

To interwork the redirection number at the O-MGCF it can be needed to create placeholder History entries. Such a 
History entry has to provide a hi-targeted-to-uri with a placeholder value "unknown@unknown.invalid" a Cause 
parameter and a hi-index as described within table 7.4.6.2.3.1. 

Table 7.4.6.2.3.1 : Mapping of lAM to SIP INVITE request 



ISUP Parameter or IE 


Derived value of 
parameter field 


SIP component 


Value 


lAM 




INVITE request 




Redirecting number 




History-Info header field 


hi-targeted-to-uri of the 
penultimate created hi-entry IF 
Redirection counter exceed 1 
ELSE no mapping 


Nature of address indicator: 


"national (significant) 
number" 


hi-targeted-to-uri 


Add CC (of the country where 
the MGCF is located) to Generic 
Number Address Signals then 
map to user portion of URI 
scheme used. 
Addr-spec 

"+" CC NDC SN mapped to user 
portion of URI scheme used 


"international number" 


IVIap complete Redirection 
number Address Signals to user 
portion of URI scheme used. 
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ISUP Parameter or IE 


Derived value of 
parameter field 


SIP component 


Value 


Address Signals 


If NOA is "national 

(significant) number" 

then the format of the 

Address Signals is: 

NDC + SN 

If NOA is "international 

number" 

then the format of the 

Address Signals is: 

CC + NDC + SN 


hi-targeted-to-uri 


"+" CC NDC SN mapped to 
userinfo portion of URI scheme 
used 


Redirecting number 


APRI 


Privacy header field that 
corresponds to the 
penultimate hi-targeted- 
to-uri entry in the History- 
Info header 


Priv-value 


"presentation 
restricted' 


"history 


"presentation allowed' 


Privacy header field absent or 
"none" (NOTE 3) 


Redirection Information 


Redirecting indicator 


Privacy header field that 
corresponds to the 
penultimate hi-targeted- 
to-uri entry in the History- 
Info header 


Priv-value 


Call diverted 


"none" (NOTE 4) 


Call diverted, all 
redirection info 
presentation restricted 


"history 


Redirection Information 


Redirection counter 

1 


hi-index 


Number of diversions are shown 

due to the number of hi-index 

Entries 

Index for original called Party 

Number = 1 

Address Signals (CdPN) 

Number = 1.1 


2 


Index for original called Party 

Number = 1 

Index for Redirecting number 

with Index = 1.1 

Address Signals (CdPN) 

Number =1.1.1 


N 


Index for original called Party 
Number = 1 

Placeholder History entry with 
Index = 1.1 

Fill up 

Index for Redirecting Number 

with = 1+[(N-1)*".1"] 

Index for Address Signals 

(CdPN) 

= 1+N*".1"(e.g. N=3-^ 1.1.1.1) 


Redirection Information 


Redirecting Reason 

and 

Original Redirection 

Reason 

(N0TE1) 


hi-targeted-to-uri; 
Reason header as 
defined in IETF RFC 
4244 [91] with cause 
parameter. 

For a placeholder History 
entry the value "404" 
shall be taken (NOTE 2). 
Cause parameter for 
redirecting reason will be 
put in the entry of 
redirecting number, and 
cause parameter for 
original redirection 
reason will be put in the 
entry of original called 
party number. 


Cause parameter value 


unknown 


404 


unconditional 


302 


User Busy 


486 


No reply 


408 


Deflection during 
alerting 


302 


Deflection immediate 
response 


302 


Mobile subscriber not 
reachable 


503 
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ISUP Parameter or IE 


Derived value of 
parameter field 


SIP component 


Value 


Called Party Number 


See Redirecting 
number 


History-Info header field 
see hi-targeted-to-uri 


URI of the last hi-targeted-to-uri 
entry of History-Info header field 


Original Called Party 
Number 


See Redirecting 
number 


History-Info header field 
see hi-targeted-to-uri 


URI of first hi-targeted-to-uri 
entry of History-Info header field 


Original Called Party 
Number 


APRI 


Privacy header field of 
the first hi-targeted-to-uri 
entry of History-Info 
header 


Priv-value 


"presentation 
restricted' 


"history 


"presentation allowed' 


"none" 


NOTE 1 : Original Redirection Reason contains only the "unknown" parameter 

NOTE 2: For all History entries except the last one a cause parameter in Reason header as defined in IETF RFC 

4244 [91] has to be included. 
NOTE 3: If the Redirecting indicator has the value "Call diverted, all redirection info presentation restricted', the 

privacy value "history shall be set. 
NOTE 4: If the redirecting number APR! has the value "presentation restricted', the privacy value "history" shall 

be set. 



7.4.6.3 Interworking at the l-MGCF 

7.4.6.3.1 General 

This subclause describes the interworking of the Call Forwarding information at the I-MGCF. 

7.4.6.3.2 Interworking from SIP to ISUP 

Table 7.4.6.3.2.1 : Mapping of SIP to ISUP messages 



->Message received from SIP 


^Message send to BICC/ISUP 


INVITE request 


lAM 
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Table 7.4.6.3.2.2: Mapping of History-Info header field to ISUP Redirecting number 



Source SIP header field 
and component 


Source 

Component 

value 


Redirecting number 


Derived value of parameter field 


latest History-Info header 
field entry containing a 
Reason header as defined 
in IETF RFC 4244 [91] with 
cause parameter value as 
listed in the 

cause parameter row in 
table 7.4.6.2.2.4 (Note 1) 




Redirecting number 




hi-targeted-to-uri 
appropriate global number 
portion of the URI, 
assumed to be in form 
"+" CC + NDC + SN 


CC 


Nature of address indicator 


If CC is equal to the country code of the 
country where IVIGCF is located AND 
the next ISUP node is located in the 
same country, then set to "nationai 
(significant) number" else set to 
" internationai number" 


CC, NDC, SN 


Address signals 


If NOA is "national (significant) number" 

then set to 

NDC-i-SN. 

If NOA is "international number" 

then set to CC + NDC + SN 


Privacy header field, 
priv-value component 
in History-Info header field 
as specified in this table 
(NOTE 2) 


"history or 
"session" or 
"header" 


APRI 


"presentation restricted' 


Privacy 
header field 
absent or 
"none" 


"presentation allowed' 


NOTE 1 : If it is SIP URI and doesn"t contain " user=phone" , mapping to redirecting number is impossible, 

therefore no need to generate Redirecting number 
NOTE 2: It is possible that an entry of the History-Info header field itself is marked as restricted or the whole 

History-Info header. 
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Table 7.4.6.3.2.3: Mapping of History-Info hieader to ISUP Redirection Information 



Source SIP header field 
and component 


Source Component 
value 


Redirection 
Information 


Derived value of parameter field 


Privacy header field, and in 
History-Info header field in 
the priv-value component of 
the last hi-targeted-to-uri 
containing a Reason 
header as defined in IETF 
RFC 4244 [91] with cause 
parameter value as listed in 
the cause parameter row in 
this table 


"history" or "sess/orf'or 
"headei" 

for the Privacy SIP 
header or for the hi- 
targeted-to-uri entry 


Redirecting 
indicator 


Call diverted, all redirection info 
presentation restricted 


Privacy header field 
and the privacy 
component of the hi- 
targeted-to-uri entry 
either absent 
or 
set to "none" 


Call diverted 






Original 
redirection reason 


Unknown 


Cause parameter in the last 
hi-targeted-to-uri containing 
a Reason header as 
defined in IETF RFC 4244 
[91] 


Cause parameter 
value 


Redirecting 
Reason 


Redirecting Reason 


302 


Deflection immediate response 


486 


User busy 


408 


No reply 


503 


Mobile subscriber not reachable 


All other values 


unknown 


Hi-index 




Redirection 
counter 


number of History entries containing a 
cause-param with value as listed in the 
cause-param row in this table (NOTE) 


NOTE: If the determined number of redirection in SIP exceeds the ISUP maximum parameter value, the IVIGCF 
shall set the Redirection counter to its maximum value. For instance, in ISUP ITU-T Q.763 [4], the 
Redirection counter parameter cannot exceed 5. 



Table 7.4.6.3.2.4: IVIapping of IHistory-lnfo hieader field to ISUP Original Called number 



Source SIP header field 
and component 


Source 

Component 

value 


Original called number 


Derived value of parameter field 






Numbering Plan Indicator 


"ISDN (Telephony) numbering plan 
(Recommendation E. 164)" 


hi-targeted-to-uri of 1^' hi- 
targeted-to-uri containing a 
Reason header as defined 
in IETF RFC 4244 [91] with 
cause parameter; 
appropriate global number 
portion of the URI, 
assumed to be in form 
"+" CC + NDC + SN (NOTE 
1) 


CC 


Nature of address indicator 


If CC is equal to the country code of the 
country where MGCF is located AND 
the next ISUP node is located in the 
same country, then set to "national 
(significant) numbei" else set to 
"international numbei" 


CC, NDC, SN 


Address signals 


If NOA is "national (significant) numbei" 

then set to 

NDC-i-SN. 

If NOA is "international numbei" 

then set to CC + NDC + SN 


priv-value component 
in History-Info header field 
of the History-Info header 
field entry as defined above 
in this table (NOTE 2) 


"historf or 
"session" or 
"headei" 


APRI 


"presentation restricted' 


Privacy 
header field 
absent or 
"none" 




"presentation allowed' 


NOTE 1 : If it is SIP URI and doesn"t contain " user=phone" , mapping to Original Called number is impossible, 

therefore no need to generate Original Called number 
NOTE 2: It is possible that an entry of the History-Info header field itself is marked as restricted or the whole 

History-Info header. 



ETSI 



3GPP TS 29.163 version 9.13.0 Release 9 



126 



ETSI TS 129 163 V9.13.0 (2013-04) 



Table 7.4.6.3.2.5: Mapping of INVITE to lAM 



INVITE 




lAM 




History-Info header 
field 


See table 7.4.6.3.2.2 


Redirecting 
number 


See table 7.4.6.3.2.2 


History-Info header 
field 


See table 7.4.6.3.2.3 


Redirection 
Information 


See table 7.4.6.3.2.3 


Cause parameter in 
the last hi-targeted-to- 
uri containing a 
Reason header as 
defined in IETF RFC 
4244 [91] 


Cause parameter value 


Redirection 
Information 


Redirecting Reason 


486 


User busy 


408 


No reply 


302 


Deflection immediate response 


503 


Mobile subscriber not reachable 


All other values 


unknown 


History-Info header 
field 


See table 7.4.6.3.2.4 


Original Called 
Number 


See table 7.4.6.3.2.4 



7.4.6.3.3 



Interworking from ISUP to SIP 

Table 7.4.6.3.3.1 : lUlapping of ISUP to SIP lUlessages 



<-Message sent to SIP 


<-Message Received from BICC/ISUP 




181 (Call is Being forwarded) 


ACIVI no indication with Redirection number and call 
diversion information (CFU, CFB, CDI) 


See table 7.4.6.3.3.3 


180 (Ringing) 


ACI\/1 indicating ringing, OBCI: Call diversion may occur 
(CFNR, CDa) 


See subclause 7.2.3.1 .4 


181 (Call is Being forwarded) 


CPG indicating progress or subsequent diversion 
indicated in the CPG with Redirection number and call 
diversion information (CFNR, CDa) 


See table 7.4.6.3.3.4 


180 (Ringing) 


CPG indicating ringing and Redirection number 
restriction parameter 


See table 7.4.6.3.3.5 


200 (OK) 


ANM and Redirection number restriction parameter 


See table 7.4.6.3.3.6 



Table 7.4.6.3.3.2: IVIapping of ISUP Redirection Number Restriction to History-Info header field 



Redirection Number 
Restriction 


Derived value of parameter field 


SIP component 


Value 


Presentation restricted 
indicator 


"Presentation restricted' 




"History" 


"Presentation allowed' or absent AND a previous 
received notification subscription option was NOT 
"presentation not allowed' OR was NOT 
"presentation allowed without redirection numbei" 




Privacy header 
field absent 
or 
"none" 
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Table 7.4.6.3.3.3: Mapping of ACM -^181 (Call Is Being Forwarded) response 



ISUP Parameter 


Derived value of 
parameter field 


SIP component 


Value 


Generic notification 
indicators 


Call is diverting 










1"^' History-info header 
having an index = 1 
(N0TE1) 


Placeholder URI 
"unknown@unknown. in valid' 


Redirection number 




2™ History-Info header 
field having an index 1.1 


hi-targeted-to-uri: 


Nature of address 
indicator: 


"national (significant) 
number" 


hi-targeted-to-uri 


Add CC (of the country where the 
MGCF is located) to Redirection 
number Address Signals then map to 
user portion of URI scheme used. 
Addr-spec 

"+" CC NDC SN mapped to user 
portion of URI scheme used according 
to the rules of 3GPP TS 24.604 [60] 
subclause 4.5.2.6.4 item c 




"international number" 




Map complete Redirection number 
Address Signals to user portion of URI 
scheme used according to the rules of 
3GPP TS 24.604 [60] subclause 
4.5.2.6.4 item c 


Address Signals 


If NOA is "national 

(significant) number" 

then the format of the 

Address Signals is: 

NDC + SN 

If NOA is "international 

number" 

then the format of the 

Address Signals is: 

CC + NDC + SN 


hi-targeted-to-uri 


"+" CC NDC SN mapped to userinfo 
portion of URI scheme used 


Call diversion 
information 


Redirecting Reason 


Reason header as defined 
in IETF RFC 4244 [91] 
with cause value in the 
penultimate hi-entry 
(NOTE 2) 


Cause parameter value 


Unknown/not available 


404 


Unconditional 


302 


User busy 


486 


No reply 


408 


Deflection immediate 
response 


302 


Deflection during 
alerting 


302 


Mobile subscriber not 
reachable 


503 


Notification 
subscription option 


Privacy associated with 
Redirection number hi- 
targeted-to-uri (NOTE 2) 


Roles 


unknown 


Escaped Privacy value is set 
according to the rules of 3GPP TS 
24.604 [60] subclause 4.5.2.6.4 item c 


presentation not 
allowed 


A 181 Call is Being Forwarded shall 
not be sent 


presentation allowed 
with redirection number 


Escaped Privacy value is set 
according to the rules of 3GPP TS 
24.604 [60] subclause 4.5.2.6.4 item c 


presentation allowed 
without redirection 
number 


Escaped Privacy value is set 
according to the rules of 3GPP TS 
24.604 [60] subclause 4.5.2.6.4 item c 


NOTE 1 : It is necessary to create two History-Info header entries to carry both Redirection number and Call 
diversion information. Since the original called number is not available from the ISUP message a 
placeholder URI is included in the first entry. Only two entries are provided because the number of 
diversions is not available. 

NOTE 2: Needs to be stored for a possible inclusion into subsequent messages. 
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Table 7.4.6.3.3.4: Mapping of CPG -> 181 (Call Is Being Forwarded) response 



ISUP Parameter 


Derived value of 
parameter field 


SIP component 


Value 


Event Indicator 


Progress 






Generic notification 
indicators 


Call is diverting 










1" History-Info 
header having an 
index =1 (N0TE1) 


Placeholder URI 

" unknown@unknown. invalid' 


Redirection number 




2™ History-Info 
header field having 
an index = 1.1 


hi-targeted-to-uri: 


Nature of address 
indicator 


"national (significant) 
number" 


hi-targeted-to-uri 


Add CC (of the country where the MGCF is 
located) to Redirection number Address 
Signals then map to user portion of URI 
scheme used. 
Addr-spec 

"+" CC NDC SN mapped to user portion of 
URI scheme used according to the rules of 
3GPP TS 24.604 [60] subclause 4.5.2.6.4 
item c 




"international number" 


hi-targeted-to-uri 


IVIap complete Redirection number Address 
Signals to user portion of URI scheme used 
according to the rules of 3GPP TS 24.604 
[60] subclause 4.5.2.6.4 item c 


Address Signals 


If NOA is "national 

(significant) number" 

then the format of the 

Address Signals is: 

NDC + SN 

If NOA is "international 

number" 

then the format of the 

Address Signals is: 

CC + NDC + SN 


hi-targeted-to-uri 


"-I-" CC NDC SN mapped to userinfo portion 
of URI scheme used 


Call diversion 
information 


Redirecting Reason 


Reason header as 
defined in IETF RFC 
4244 [91] with cause 
value in the 
penultimate hi-entry 
(NOTE 2) 


Cause parameter value 


Unknown/not available 


404 


Unconditional 


302 


User busy 


486 


No reply 


408 


Deflection immediate 
response 


302 


Deflection during 
alerting 


302 


Mobile subscriber not 
reachable 


503 


Notification 
subscription option 


Privacy associated 
with Redirection 
number hi-targeted- 
to-uri (NOTE 2) 


Roles 


unknown 


Escaped Privacy value is set according to 
the rules of 3GPP TS 24.604 [60] subclause 
4.5.2.6.4 item c 


presentation not 
allowed 


A 181 Call is Being Forwarded shall not be 
sent 


presentation allowed 
with redirection number 


Escaped Privacy value is set according to 
the rules of 3GPP TS 24.604 [60] subclause 
4.5.2.6.4 item c 


presentation allowed 
without redirection 
number 


Escaped Privacy value is set according to 
the rules of 3GPP TS 24.604 [60] subclause 
4.5.2.6.4 item c 


NOTE 1 : It is necessary to create two History-Info header entries to carry both Redirection number and Call 
diversion information. Since the original called number is not available from the ISUP message a 
placeholder URI is included in the first entry. Only two entries are provided because the number of 
diversions is not available. 

NOTE 2: Needs to be stored for a possible inclusion into subsequent messages. 
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Table 7.4.6.3.3.5 addresses two separate conditions: the CPG is received from the diverting exchange in which case the 
Call diversion information is included; and the CPG is received from the diverted-to exchange in which case the Call 
diversion information is not included. Interworking for both conditions is shown. 

Table 7.4.6.3.3.5: Mapping of CPG -^ 180 (Ringing) response 



ISUP Parameter 


Derived value of 
parameter field 


SIP component 


Value 


Event Indicator 


Alerting 










1^' history-info header 
having an index = 1 (NOTE 

1) 


Placeholder URI 
"unknown@unknown. invalid' 


Redirection number 




2™ History-Info header field 
having an index =1.1 


See table 7.4.6.3.3.3 


Call diversion information 


Redirecting Reason 


Cause parameter in the 
latest entry 

Local policy also allows to 
put a Reason header as 
defined in IETF RFC 4244 
[91] with cause parameter 
(NOTE 2) 


Cause parameter value 


Unknown/not available 


404 


Unconditional 


302 


User busy 


486 


No reply 


408 


Deflection immediate 
response 


302 


Deflection during 
alerting 


302 


Mobile subscriber not 
reachable 


503 


Notification 
subscription option 


Privacy associated with 
Redirection number hi- 
targeted-to-uri (NOTE 2) 


Roles 


unknown 


Escaped Privacy value is set 
according to the rules of 
3GPP TS 24.604 [60] 
subclause 4.5.2.6.4 item c 


presentation not 
allowed 


The 180 Ringing response 
shall be sent without the the 
History-Info header field 
included 


presentation allowed 
with redirection number 


Escaped Privacy value is set 
according to the rules of 
3GPP TS 24.604 [60] 
subclause 4.5.2.6.4 item c 


presentation allowed 
without redirection 
number 


Escaped Privacy value is set 
according to the rules of 
3GPP TS 24.604 [60] 
subclause 4.5.2.6.4 item c 


If no Call diversion 
information parameter is 
present 




Reason header as defined in 
IETF RFC 4244 [91] with 
cause value in the 
penultimate hi-entry 


Value stored from a previous 
received ACIVI or CPG. See 
tables 7.4.6.3.3.3 and 
7.4.6.3.3.4 


Privacy associated with 
Redirection number hi- 
targeted-to-uri 


Value stored from a previous 
received ACIVI or CPG. See 
tables 7.4.6.3.3.3 and 
7.4.6.3.3.4 


Redirection number 
restriction 






See table 7.4.6.3.3.2 


NOTE 1 : It is necessary to create two History-Info header entries to carry both Redirection number and 
Redirecting reason. Since the original called number is not available from the ISUP message a 
placeholder URI is included in the first entry. Only two entries are provided because the number of 
diversions is not available. 

NOTE 2: Needs to be stored for a possible inclusion into subsequent messages. 



£75/ 



3GPP TS 29.163 version 9.13.0 Release 9 



130 



ETSI TS 129 163 V9.13.0 (2013-04) 



Table 7.4.6.3.3.6: Mapping of ANM -> 200 (OK) response (to INVITE request) 



ISUP Parameter 


Derived value of 
parameter field 


SIP component 


Value 






1^' History-Info header 
having an index = 1 (NOTE) 


Placeholder URI 
"unknown@unknown. invalid' 


Redirection number 




2™ History-Info header field 
having an index = 1.1 


See table 7.4.6.3.3.3 






Reason header as defined in 
IETF RFC 4244 [91] with 
cause value in the 
penultimate hi-entry 


Value stored from a 
previously received ACIVI or 
CPG. See tables 7.4.6.3.3.3 
and 7.4.6.3.3.4 


Redirection number 
restriction 






See table 7.4.6.3.3.2 


NOTE: It is necessary to create two History-Info header entries to carry both Redirection number and 
Redirecting reason. Since the original called number is not available from the ISUP message a 
placeholder URI is included in the first entry. Only two entries are provided because the number of 
diversions is not available. 



7.4.7 Void 

7.4.8 Explicit Call Transfer (ECT) 

When the MGCF receives a FAC message with Generic notification indicator coded as "Call transfer active" or "call 
transfer alerting" and a CPG with Generic notification indicator coded as "Remote hold" was received previously for the 
current communication, the action described in table 24be applies. In all other cases the actions of the MGCF at the 
ISUP/BICC side are described in ITU-T Recommendation Q.732.7 [42] under the clause "Interactions with other 
networks". 

Table 24be: Mapping between ISUP and SIP for the Explicit Communication Transfer supplementary 

service 



ISUP message 


IVIapping 


FAC with a "call transfer, active" or "call 
transfer, alerting" Generic notification 
indicator 


As described for CPG message with a "remote retrieval" Generic notification 
indicator in subclause 7.4.10.2 



7.4.9 Call Waiting 



The actions of the MGCF at the ISUP/BICC side are described in ITU-T Q.733.1 [42] under the clause "Interactions 
with other networks". 

7.4.10 Call Hold 

The service is interworked as indicated in 3GPP TS 23.228 [12]. 

7.4.10.1 Session hold initiated from the IM CN subsystem side 

The IMS network makes a hold request by sending an UPDATE or re-INVITE message with an "inactive" or a 
"sendonly" SDP attribute (refer to RFC 3264 [36]), depending on the current state of the session. Upon receipt of the 
hold request from the IMS side, the MGCF shall send a CPG message to the CS side with a "remote hold" Generic 
notification indicator. To resume the session, the IMS side sends an UPDATE or re-INVITE message with a "recvonly" 
or "sendrecv" SDP attribute, depending on the current state of the session. Upon receipt of the resume request from the 
IMS side, the MGCF shall send a CPG message to the CS side with a "remove retrieval" Generic notification indicator. 
However, the I-MGCF shall not send a CPG message upon reception of SDP containing "inactive" media within an 
initial INVITE request establishing a new SIP dialogue and upon reception of the first subsequent SDP activating those 
media. 
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The user plane interworking of the hold/resume request is described in the subclause 9.2.9. 





2. BICC/ISUP: CPG (Hold) 


MGCF 










1 . SIP: UPDATE [SDP, a=sendonly/ 
inactive] 














3. S!P: 200 OK [SDP] 











5. BICC/ISUP: CPG (Retrieve) 




4. SIP: UPDATE [SDP, a=sendrecv/ 
recvonly] 












6. SIP: 200 OK FSDPl 









Figure 30a: Session hold/resume initiated from the IIVI CN subsystem side 



7.4.10.2 



Session hold initiated from the CS network side 



If an IVIGCF receives a CPG message with "remote hold" and there is no dialog established towards the UE the MGCF 
shall send an UPDATE or re-INVlTE request containing an SDP offer with "sendonly" or "inactive" media, as 
described in IETF RFC 3264 [36], when the first dialog is established. For an early dialog only UPDATE shall be used. 

When an IVIGCF receives a CPG message with a "remote hold" Generic notification indicator and the media on the IMS 
side are "sendrecv" or "recvonly" , the MGCF shall forward the hold request by sending an UPDATE request on the 
early dialog which was last established containing an SDP offer with "sendonly" if the stream was previously 
"sendrecv" or "inactive" if the stream was previously "recvonly" media, as described in IETF RFC 3264 [36]. 

If an additional early dialog is established during the "remote hold" condition the MGCF shall send an UPDATE 
request containing an SDP offer with "sendonly" or "inactive" media on the new early dialog, as described in IETF RFC 
3264 [36]. 

If an UPDATE request with an SDP offer is received on one of the early dialogs for a call in the "remote hold" 
condition the MGCF shall send an appropriate SDP answer followed by a new UPDATE request including SDP with 
"sendonly" or "inactive" media on the dialog, as described in IETF RFC 3264 [36]. 

If an MGCF receives a 200 OK (INVITE) response on an early dialog for which the call is in a "remote hold" condition 
the MGCF shall send an UPDATE or re-INVITE request containing an SDP offer with "sendonly" or "inactive" media 
on the dialog where 200 OK (INVITE) was received, as described in IETF RFC 3264 [36]. 

If the MGCF receives a CPG with Generic Notification Indicator "remote retrieval" and there is an early dialog on IMS 
side then a SIP UPDATE request (indicating call retrieval) shall be sent if the call hold service had been invoked on the 
early dialog before. For each subsequent early dialog for which the MGCF receives an 18x response or an UPDATE 
request with an SDP offer, the MGCF shall send SIP UPDATE indicating call retrieval after a possible SDP answer to 
the SDP offer, if that dialog had received a call hold indication before. 

If the MGCF receives a CPG with Generic Notification Indicator "remote retrieval" and there is a confirmed dialog on 
IMS side then a SIP re-INVITE or UPDATE request (according to implementation option) shall be sent for this dialog 
only if the call hold service had been invoked for this dialog before. 
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When an MGCF receives a CPG message with a "remote retrieval" Generic notification indicator and the media on the 
IMS side are "sendonly" or "inactive" , the MGCF shall forward the resume request by sending an UPDATE or re- 
INVITE message containing an SDP offer with "sendrecv" if the stream was previously "sendonly" or "recvonly" if the 
stream was previously "inactive" media, as described in IETF RFC 3264 [36]. 

If the MGCF receives a CPG with "remote hold" or "remote retrieval" before answer, it shall forward the request using 
an UPDATE message. If the MGCF receives a CPG with "remote hold" or "remote retrieval" after answer, it should 
forward the request using re-INVITE but may use UPDATE. 

If link aliveness information is required at the IM-MGW while the media are on hold, the O-MGCF should provide 
modified SDP RR and RS bandwidth modifiers specified in IETF RFC 3556 [59] within the UPDATE or re-INVITE 
messages holding and retrieving the media to temporarily enable RTCP while the media are on hold, as detailed in 
subclause 7.4 of 3GPP TS 26.236 [32]. If no link aliveness information is required at the IM-MGW, the O-MGCF 
should provide the SDP RR and RS bandwidth modifiers previously used. 

The interworking does not impact the user plane, unless the MGCF provides modified SDP RR and RS bandwidth 
modifiers within the UPDATE or re-INVITE messages. If the MGCF provides modified SDP RR and RS bandwidth 
modifiers to the IMS side, the MGCF shall also provide modified SDP RR and RS bandwidths to the IM-MGW, as 
described in the subclause 9.2.10. 





MGCF 




1 . BICC/ISUP: CPG (Hold) 












2. S!P: UPDATE [SDP, a=sendonly/ 
inactive] 




3. SIP: 200 OK [SDP] 









4. BICC/ISUP: CPG (Retrieve) 




5. SIP: UPDATE [SDP, a=sendrecv/ 
recvonly] 












6. SIP: 200 OK [SDP] 











Figure 30b: Session hiold/resume initiated from thie CS networl< side 



7.4.1 1 Call Completion on busy subscriber 

The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.733.3 [42] under the 
clause "Interactions with other networks". 

7.4.1 2 Completion of Calls on No Reply (CCNR) 

The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.733.5 [42] under the 
clause "Interactions with other networks". 
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7.4.13 Terminal Portability (TP) 

Terminal Portability is defined as an ISUP supplementary service within ITU-T Rec. Q.733.4. [42]. 

A Suspend message containing the Suspend/Resume indicators set to "ISDN subscriber initiated" shall be treated like a 
CPG with "remote hold" in Section 7.4.10 Resume message containing the Suspend/Resume indicators set to "ISDN 
subscriber initiated" shall be treated like a CPG with "remote retrieval" in Section 7.4.10. 

7.4.14 Conference calling (CONF) / Three-Party Service (3PTY) 

The default behaviour of the MGCF at the ISUP/BICC side is described in ITU-T Recommendation Q.734.1[42] under 
the clause "Interactions with other networks". In addition, the MGCF may apply the interworking from ISUP to SIP 
described in table 24aa. 

Alternatively, the MGCF may apply the interworking to the Conference supplementary service described in subclause 
7.5.6. 

Table 24aa: Mapping between ISUP and SIP for the Conference Calling (CONF) and Three-Party 

Service (3PTY) supplementary service 



ISUP message 


Mapping 


CPG with a "Conference established" 
Generic notification indicator 


As described for CPG message with a "remote retrieval" Generic 
notification indicator in subclause 7.4.10.2 


CPG with a "Conference disconnected" 
Generic notification indicator 


As described for CPG message with a "remote retrieval" Generic 
notification indicator in subclause 7.4.10.2 


CPG with an "isolated" Generic 
notification indicator 


As described for CPG message with a "remote hold" Generic notification 
indicator in subclause 7.4.10.2 


CPG with a "reattached" Generic 
notification indicator 


As described for CPG message with a "remote retrieval" Generic 
notification indicator in subclause 7.4.10.2 



7.4.15 Void 

7.4.1 6 Closed User Group (CUG) 

The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.735.1[42] under the 
subclause 1.5.2.4.2 "Exceptional procedures". 

7.4.17 Multi-Level Precedence and Pre-emption (MLPP) 

The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.735.3 [42] under the 
clause "Interactions with other networks". 

7.4.18 Global Virtual Network Service (GVNS) 

The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.735.6 [42] under the 
clause "Interactions with other networks". 

7.4.19 International telecommunication charge card (ITCC) 

An International Telecommunication charge card call is a basic call and no additional treatment is required by the 
MGCF. 

7.4.20 Reverse charging (REV) 

The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.736.3 [42] under the 
clause "Interactions with other networks". 
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7.4.21 User-to-User Signalling (UUS) 

7.4.21.1 User-to-User Signalling (UUS) service 1 (implicit) 



7.4.21.1.0 



General 



The coding of the User-user information element is described within ITU-T Recommendation Q.737.1[42]. The User- 
to-User header field is defined within draft-ietf-cuss-sip-uui [99]. A package for interworking user-to-user information 
with the ISDN is defined by IETF draft-ietf-cuss-sip-uui-isdn [99 A]. 



7.4.21.1.1 



Void 



7.4.21.1.2 



Incoming Call Intenworking from SIP to ISUP at l-MGCF 



On the receipt of a User-to-User header field with the "purpose" header field parameter set to "uui-isdn", or a User-to- 
User header field without a "purpose" parameter, with "encoding" header field parameter set to "hex" or without an 
"encoding" parameter, with "content" header field parameter set to "uui-isdn" or without a "content" parameter, that is 
valid as defined by IETF draft-ietf-cuss-sip-uui-isdn [99 A], the I-MGCF shall map the content of the "uuidata" field to 
the "protocol discriminator" and "user information" parameters of the user-user information element. 

The "length of user-user contents" parameter shall be set by the I-MGCF according to the normal procedures. 

The I-MGCF maps the messages transporting the user-user information according to the normal interworking 
procedures (see table 24ab). 

Table 24ab: Mapping of the User-to-User header field to the ISUP user-to-user information parameter 



SIP parameter -^ 


-^ ISUP parameter | 


SIP header field 


Source 
component value 


ISUP parameter 
name 


ISUP parameter field 


User-to-User 


uuidata 


User-to-user 


Protocol discriminator and user information 



7.4.21.1.3 



Outgoing Call Interworking from ISUP to SIP at 0-MGCF 



On the receipt of the user-to-user information parameter the O-MGCF shall map the protocol discriminator and user 
information parameter fields to the uuidata field of the User-to-User header field (see table 24ac). 

If sent, the "purpose", "content" and "encoding" header field parameters are not mapped and are set in accordance with 
IETF draft-ietf-cuss-sip-uui-isdn [99 A] 

The O-MGCF maps the messages transporting the user-to-user information parameters according to the normal 
interworking procedures. 

Table 24ac: Mapping of the ISUP user-to-user information parameter to the User-to-User header field 



-^ ISUP parameter 


-^ SIP parameter | 


ISUP parameter 
name 


ISUP parameter field 


SIP header field 


Source component 
value 


User-to-user 


Protocol discriminator and user information 


User-to-user 


uuidata (NOTE) 


NOTE: The IVIGCF shall always send uuidata as a token (see IETF draft-ietf-cuss-sip-uui [99]). The letters used for 
the hex digits shall always be capital form. 



7.4.21.2 User-to-User Signalling (UUS) service 1 (explicit) 

The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.737.1 [42] under the 
clause "Interaction with other networks". 
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7.4.21 .3 User-to-User Signalling (UUS) service 2 (explicit) 

The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.737.1 [42] under the 
clause "Interaction with other networks". 

7.4.21 .4 User-to-User Signalling (UUS) service 3 (explicit) 

The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.737.1 [42] under the 
clause "Interaction with other networks". 

7.4.22 Multiple Subscriber Number (MSN) 

A MSN call is a basic call and no additional treatment is required by the MGCF. 

7.4.23 Anonymous Call rejection 

This section describes the interworking of the ETSI ACR service as described ETSI EN 300 356-21 [71]. 

7.4.23.1 ISUP-SIP protocol interworking at the l-MGCF 

If ISUP Cause Value field in the ISUP REL includes Cause Value 24 "call rejected due to ACR supplementary service " 
the I-MGCF shall map this to a 433 (Anonymity Disallowed) as described in RFC 5079 [77]. 

7.4.23.2 SIP-ISUP protocol interworking at the 0-MGCF 

If the response is a 433 (Anonymity Disallowed) response, then this response shall be mapped to the ISUP Cause Value 
field 24 "call rejected due to ACR supplementary service" in the ISUP REL. 

7.5 IMS Supplementary Services 

The following subclauses describe the MGCF behaviour related to supplementary services as defined in ITU-T 
Recommendations Q.730 to ITU-T Q.737 [42] when interworking with an IMS which uses a Multimedia Telephony 
Application Server (MTAS) providing supplementary services according to 3GPP TS 24.173 [88]. The support of the 
related procedures is optional. 

7.5.1 Originating Identification Presentation (OIP) and Originating 
Identification Restriction (OIR) 

The mapping of Originating Identification Presentation (OIP) and Originating Identification Restriction (OIR); 
supplementary service with the CLIP/CLIR PSTN/ISDN Supplementary Service is the same mapping as described in 
subclause 7.4.1. The Service itself is described within 3GPP TS 24.607 [63]. 

7.5.2 Terminating Identification Presentation (TIP) and Terminating 
Identification Restriction (TIR) 

7.5.2.1 General 

The protocol specification of the Terminating Identification Presentation and Terminating Identification Restriction 
supplementary services is described in 3GPP TS 24.608 [64]. 

The procedures for mapping of the connected number described within subclause 7.4.2 shall apply. 

7.5.2.2 Interworking at the 0-MGGF 

For the mapping of lAM to the INVITE request: 
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If an Optional forward call indicators parameter in the lAM is received where the bit H Connected line identity request 
indicator is set to "requested", then the option tag "from-change" shall be add to the Supported header field. See table 
7.5.2.2.1. 

Table 7.5.2.2.1 : Mapping of ISUP lAM to SIP INVITE request 



ISUP Parameter 


Derived value of parameter 
field 


Source SIP header field 
and component 


Source Component 
value 


Optional forward call indicator 


Connected line identity request 
indicator \s set to "requested" 


Supported 


"from-change" 



NOTE: The presence of "from-change" enables the reception of Generic Number with Number qualifier 

parameter field set to additional connected, if available. As per 3GPP TS 24.608 [64] the presence of 
"from-change" tag is not a criterion for TIP service. 

If a provisional or final response including the option tag "from-change" is received, then the O-MGCF shall: 

if a 200 (OK) response to the INVITE request is received, start timer Ttiri; and 

store the 200 (OK) response, without interworking it. 

Otherwise the 200 (OK) response (to the INVITE request) shall be mapped as described in subclause 7.2.3.2.7a. 

If an UPDATE request is received containing a changed From header field before the timer TTIRI expired, then the 
O-MGCF shall: 

stop timer Tjiri; 

map the From header field received in the UPDATE request to the Generic number in the ANM as shown in 
table 7.5.2.2.2 and table 7.5.2.2.3; 

if the UPDATE request includes a P-Asserted-Identity header field that is different from the one within the 
stored 200 (OK) response, the latest received P-Asserted-Identity header field shall be mapped to the connected 
number as described table 24; and 

map the parameters needed to be mapped of the stored 200 (OK) response to an ANM as described in subclause 
7.4.2.2.3, modified by the changed mapping steps of the From and P-Asserted-Identity header fields. 

When Ttiri expires, then the stored 200 (OK) response (to the INVITE request) response shall be mapped as described 
in subclause 7.4.2.2.3. 

Table 7.5.2.2.2: Mapping of SIP UPDATE request to ISUP ANM/CON 



ANM/CON 


UPDATE 


Generic number 


From header field 
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Table 7.5.2.2.3: Mapping of SIP From header field to ISUP Generic Number 
("additional connected number") parameter 



Source SIP header 
field and component 


Source 

component 

value 


Generic Number parameter 
field 


Derived value of parameter field 


- 


- 


Number Qualifier Indicator 


"additional connected numbei" 


From, userinfo 
component of URI 
assumed to be in form 
"+" CC + NDC + SN 


CC 


Nature of Address Indicator 


If CC is equal to the country code of the 
country where l-MGCF is located AND 
the next ISUP node is located in the 
same country, then set to "national 
(significant) number" else set to 
"international numbei" 


- 


- 


Number Incomplete Indicator 


"complete" 


— 


— 


Numbering Plan Indicator 


"ISDN (Telephony) numbering plan 
(Recommendation E. 164)" 


Privacy, priv-value 
component 


Privacy header 
field absent 


Address Presentation 
Restricted Indicator (APRI) 


"presentation allowed' 


"none" 


"presentation allowed' 


"headei" 


"presentation restricted' 


"usei" 


"presentation restricted' 


- 


- 


Screening Indicator 


"user provided, not verified' 


From, userinfo 
component assumed to 
be in form 
"+" CC + NDC + SN 


CC, NDC, SN 


Address Signals 


If NOA is "national (significant) numbei" 

then set to 

NDC + SN. 

If NOA is "international numbei" 

then set to CC + NDC + SN 



7.5.2.3 Interworking at the l-MGCF 

For the mapping of INVITE request to lAM: 

- the bit H Connected line identity request indicator of the Optional forward call indicators parameter in the lAM 
shall be set to "requested". 

Table 7.5.2.3.1 : Void 

If a received ISUP ANM includes an ISUP Generic Number ("additional connected number") parameter, then the 
I-MGCF shall send a 200 (OK) response (to the INVITE request) including an option tag "from-change" If the initial 
INVITE was received and the Supported header field contains the "from-change" tag, the 200 (OK) response is 
followed by an UPDATE request, containing the "additional connected number" copied into the From header field as 
shown in table 7.5.2.3.2. 

The To header field of the UPDATE request is derived from the P-Asserted-Identity header field received within the 
initial INVITE request. 
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Table 7.5.2.3.2: Mapping of ANM Generic Number ("additional connected number") 
to SIP From header field in a SIP UPDATE request 



ISUP 
Parameter/field 


Value 


SIP component 


Value 


Generic Number 
Number Qualifier 
Indicator 


"additional connected 
numbei" 


From header field 


display-name (optional) and addr-spec 


Nature of Address 
Indicator 


"national (significant) 
number" 


Addr-spec 


Add "+" CC (of the country where the 
IWU is located) to Generic Number 
Address Signals then map to user 
portion of URI scheme used 


"international number" 


IVIap complete Generic Number Address 
Signals used prefixed with a "+" to user 
portion of URI scheme used 


Address 
Presentation 
restriction indicator 
(APRl) 


"presentation allowed' 




No Privacy header field or not "headei" 
or not "usei" 


"presentation restricted' 


"headei" 


Address Signals 


if NOA is "national 

(significant) number" then 

the format of the address 

signals is: 

NDC + SN 

If NOA is "international 

number" 

then the format of the 

address signals is: 

CC + NDC + SN 


Display-name 
(optional) 


display-name shall be mapped from 
Address Signals, if network policy allows 
it 


Addr-spec 


"+" CC NDG SN mapped to user portion 
of URI scheme used 



A received connected number in an ANM shall be mapped to the P-Asserted-Identity header field as shown in table 21 
of the UPDATE request. 



7.5.2.4 



Timer 



Table 7.5.2.4.1 TIR timer definition 



Symbol 


Timeout 
value 


Cause for initiation 


Normal termination 


At expiry 


Ttiri 


100-2000 milliseconds 
(default 100 milliseconds) 


On receipt of provisional or final 
response including the option tag 
"from-change" 


At the receipt of an 
UPDATE 


map the received 
200OK to an ANM 



7.5.3 void 



7.5.4 Communication Diversion (CDIV) 



7.5.4.1 



General 



The protocol specification of the Communication Diversion supplementary service is described in 3GPP TS 24.604 
[60]. The mapping of Communication Diversion supplementary service with Call Diversion services PSTN/ISDN 
supplementary service including the mapping of the optional History-Info header field as defined in IETF RFC 4244 
[91] is described. 

In case of interworking with networks which do not provide any notification of the communication diversion or 
communication redirection information (e.g. redirection counter) in the signalling system, the communication continues 
according to the basic call procedures. 
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7.5.4.2 



Interworking at the 0-MGCF 



7.5.4.2.1 



General 



For the mapping of lAM to the INVITE request no additional procedures beyond the basic call and interworking 
procedures are needed unless Call forwarding within the ISUP Network appeared. 

With regard to the backward messages the following mapping is valid. 

Table 7.5.4.2.1.1 : Mapping of SIP messages to ISUP messages 



<-Message sent to ISUP 


(-Message Received from SIP 




ACM indicating call forwarding 


181 (Call Is Being Forwarded) response 


See table 7.5.4.2.1.6 


CPG indicating call forwarding (see NOTE) 


181 (Call Is Being Forwarded) response 


See table 7.5.4.2.1.7 


ACM indicating ringing 


180 (Ringing) response 


See table 7.5.4.2.1.8 


CPG indicating Alerting (see NOTE) 


180 (Ringing) response 


See table 7.5.4.2.1.9 


ANM 


200 (OK) response 


See table 7.5.4.2.1.10 


CON 


200 (OK) response (Neither a 181 (Call Is 
Being Forwarded) response nor a 180 
(Ringing) response was received) 


See table 7.5.4.2.1.10 


NOTE: A CPG will be sent if an ACM was already sent. | 



Table 7.5.4.2.1.2: Mapping of History-Info header field to ISUP Redirection number 



Source SIP header field 
and component 


Source 

Component 

value 


Redirection number 


Derived value of parameter field 


hi-targeted-to-uri of the last 
History-Info hi-entry 
containing a cause-param 
URI parameter, as defined 
in IETF RFC 4458 [113]. 
The global number portion 
of the hi-targeted-to-uri is 
assumed to be in form 
"+" CC + NDC -1- 
SN.(NOTE) 


CC 


Nature of address indicator 


If CC is equal to the country code of the 
country where O-MGCF is located AND 
the next ISUP node is located in the 
same country, then set to "national 
(significant) numbei" else set to 
" internationai numbei". 


CC, NDC, SN 


Address signals 


If NOA is "national (significant) number" 
then set to NDC -hSN. 
If NOA is "international number" 
then set to CC + NDC + SN. 


NOTE: If it is SIP URI and doesn"t contain " user=phone" , mapping to redirection number is impossible, 

therefore no need to generate Redirection number and Redirection number restriction indicator (per 
table 7.5.4.2.1 .3), Notification subscription options can"t be set as "presentation allowed with redirection 
number". 



Table 7.5.4.2.1.3: Mapping of History-Info header field to ISUP Redirection number restriction 



Source SIP header 
field and component 


Source Component value 


Redirection number 
restriction 


Derived value of 
parameter field 


Privacy header field, 
priv-value component 


"historf or "session" or "fieader" 


Presentation restricted 
indicator 


"Presentation restricted' 


Privacy header field absent 
or "none" 


"Presentation allowed' 
or absent 
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Table 7.5.4.2.1.4: Mapping of hi-targeted-to-uri to ISUP Call Diversion Information 



Source SIP header field 
and component 


Source Component 
value 


Call Diversion 
Information 


Derived value of parameter field 


Privacy header field, 
priv-value component 


"history or "session" or 
"tieadei" 


Notification 

subscription 

options 


If the priv-value "history or "session" or 
"header is set for the History-Info 
header field or to the hist-info element 
entries concerning the redirecting (see 
table 7.5.4.3.2) and diverted to uri (see 
table 7.5.4.2.1 .2) then "presentation not 
aliowed" shall be set 
If the priv-value "history" or "session" or 
"header is set only to the hist-info 
element concerning the diverted-to uri 
then "presentation ailowed without 
redirection numbe'V shall be set 


Privacy header field 

absent 

or "none" 


Presentation aliowed with redirection 
number 


hi-targeted-to-uri cause- 
param URI parameter, as 
defined in IETF RFC 4458 
[113] of the last History-Info 
hi-entry containing such 
cause-param. 


cause-param value 


Call diversion 
information 


Redirecting Reason 


404 


Unl<nown 


302 


Unconditionai 


486 


User busy 


408 


No reply 


480 


Deflection immediate 


503 


Mobile subscriber not reachable 


487 


Deflection during alerting 



Table 7.5.4.2.1.5: Void 
Table 7.5.4.2.1.6: Mapping of 181 (Call Is Being Forwarded) -> ACM if no ACM was sent before 



Source SIP header field 
and component 


Source Component 
value 


ISUP Parameter 


Derived value of parameter 
field 


181 (Call Is Being 
Forwarded) 




ACM 








Generic notification 
indicators 


Call is diverting 


History-Info header field 


See table 7.5.4.2.1.2 


Redirection number 


See table 7.5.4.2.1.2 


Priv-value 


See table 7.5.4.2.1.3 


Redirection number 
restriction 


See table 7.5.4.2.1.3 


Priv-value 


See table 7.5.4.2.1.4 


Call diversion information 
Notification subscription 
options 


See table 7.5.4.2.1.4 


hi-targeted-to-uri;cause- 
param URI parameter as 
defined in IETF RFC 4458 
[113] of the last History-Info 
hi-entry containing such 
cause-param. 


See table 7.5.4.2.1.4 


Call diversion information 


Redirecting Reason 
See table 7.5.4.2.1.4 
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Table 7.5.4.2.1.7: Mapping of 181 (Call Is Being Forwarded)-^ CPG if ACIVI was already sent 



Source SIP header field 
and component 


Source Component 
value 


ISUP Parameter 


Derived value of parameter 
field 


181 (Call Is Being 
Forwarded) response 




CPG 








Generic notification 
indicators 


Cali is diverting 


hi-targeted-to-uri; cause- 
param URI parameter, as 
defined in IETF RFC 4458 
[113] of the last History-Info 
hi-entry containing such 
cause-param. 


486 


Event indicator 


CFB (national use) 


408 (see NOTE) 


CFNR (national use) 


302 


CFU (national use) 


Any other value, or if 
appropriate national 
use value CFB, CFNR 
or CFU is not used in a 
network, or if no 
agreement exists 
between operators to 
use theses values, or if 
no hi-targeted-to-uri 
cause-param URI 
parameter is contained 
in the SIP 181. 


PROGRESS 


History-Info header field 


See table 7.5.4.2.1.2 


Redirection number 


See table 7.5.4.2.1.2 


Priv-value 


See table 7.5.4.2.1.3 


Redirection number 
restriction 


See table 7.5.4.2.1.3 


Priv-value 


See table 7.5.4.2.1.4 


Call diversion information 
Notification subscription 
options 


See table 7.5.4.2.1.4 


hi-targeted-to-uri; cause- 
param URI parameter, as 
defined in IETF RFC 4458 
[113] of the last History-Info 
hi-entry containing such 
cause-param. 


See table 7.5.4.2.1.4 


Call diversion information 
Redirecting Reason 


See table 7.5.4.2.1.4 


NOTE: This appears in the cases of CFNR. 



Table 7.5.4.2.1.8: IVIapping of 180 (Ringing) ^ ACIVI if no ACIVI was sent before 



Source SIP header field 
and component 


Source Component 
value 


ISUP Parameter 


Derived value of parameter 
field 


180 (Ringing) response 




ACM 




History-Info header field 


If hi-targeted-to-uri of at 
least one History-Info 
hi-entry contains a 
cause-param URI 
parameter, as defined 
in IETF RFC 4458 
[1131. 


Generic notification 
indicators 


Cali is diverting 


History-Info header field 


See table 7.5.4.2.1.2 


Redirection number (NOTE) 


See table 7.5.4.2.1.2 


Priv-value 


See table 7.5.4.2.1.3 


Redirection number 
restriction (NOTE) 


See table 7.5.4.2.1.3 


Priv-value 


See table 7.5.4.2.1.4 


Call diversion information 
Notification subscription 
options (NOTE) 


See table 7.5.4.2.1.4 


hi-targeted-to-uri; cause- 
param URI parameter, as 
defined in IETF RFC 4458 
[113] of the last History-Info 
hi-entry containing such 
cause-param. 


See table 7.5.4.2.1.4 


Call diversion information 
Redirecting Reason (NOTE) 


See table 7.5.4.2.1.4 


NOTE: Parameter shall only be supplied if hi-targeted-to-uri of at least one History-Info hi-entry contains a 
cause-param URI parameter, as defined in IETF RFC 4458 [113]. 
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The mapping described within table 7.5.4.2.1.1 can only appear if the communication has already undergone a Call 
Forwarding in the ISDN/PSTN and the 180 is the first provisional response sent in backward direction. 

The IWU can indicate the call diversion in the mapping of 1 80 (Ringing) to CPG in fact if the response before was 
a 181 (Call is being forwarded). 

Table 7.5.4.2.1.9: Mapping of 180 (Ringing) -^ CPG if ACIV! was already sent 



Source SIP header field 
and component 


Source Component 
value 


ISUP Parameter 


Derived value of parameter 
field 


180 (Ringing) response 




CPG 




History-Info header field 


If hi-targeted-to-uri of at 
least one History-Info 
hi-entry contains a 
cause-param URI 
parameter, as defined 
in IETF RFC 4458 
[113]. 


Generic notification 
indicators 


Cali is diverting 






Event indicator 


ALERTING 


History-Info header field 


See table 7.5.4.2.1.2 


Redirection number 
(NOTE) 


See table 7.5.4.2.1.2 


Priv-value 


See table 7.5.4.2.1.3 


Redirection number 
restriction (NOTE) 


See table 7.5.4.2.1.3 


Priv-value 


See table 7.5.4.2.1.4 


Call diversion information 
Notification subscription 
options (NOTE) 


See table 7.5.4.2.1.4 


hi-targeted-to-uri; cause- 
param URI parameter, as 
defined in IETF RFC 4458 
[113] of the last History-Info 
hi-entry containing such 
cause-param. 


See table 7.5.4.2.1.4 


Call diversion information 
Redirecting Reason (NOTE) 


See table 7.5.4.2.1.4 


NOTE: Parameter shall only be supplied if hi-targeted-to-uri of at least one History-Info hi-entry contains a 
cause-param URI parameter, as defined in IETF RFC 4458 [113]. 



The mapping in table 7.5.4.2.1.9 appears when a 181 previously was mapped to an ACM. Therefore the state machine 
of the MGCF knows that a CDIV is in Progress. 

Table 7.5.4.2.1.10: Mapping of 200 (OK) response 



Source SIP header field 
and component 


Source Component 
value 


ISUP Parameter 


Derived value of parameter 
field 


200 (OK) response 




ANM/CON 




History-Info header field 


See table 7.5.4.2.1.2 


Redirection number 


See table 7.5.4.2.1.2 


Priv-value 


See table 7.5.4.2.1.3 


Redirection number 
restriction 


See table 7.5.4.2.1.3 



7.5.4.2.2 



Call forwarding within the ISUP Network appeared 



The following scenario shows if a Call Forwarding appears in the ISUP/PSTN and the redirected Number is within the 
SIP network. Table 7.5.4.2.2.1 should be seen as an example. 

For the mapping of 180 (Ringing) response and 200 (OK) response to the regarding ISUP messages and parameters no 
additional procedures beyond the basic call procedures are needed. 

To interwork the redirection number at the O-MGCF it can be needed to create placeholder History entries. Such a 
History entry has to provide a hi-targeted-to-uri with a placeholder value "unknown@unknown.invalid" a cause-param 
and a hi-index as described within table 7.5.4.2.2.1. 
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Table 7.5.4.2.2.1 : Mapping of lAM to SIP INVITE request 



ISUP 

Parameter 

or IE 


Derived value of parameter 
field 


SIP component 


Value 


lAM 




INVITE request 




Redirecting 
number 




History-Info header field 


hi-targeted-to-uri of the penultimate 
created hi-entry IF Redirection 
counter exceed 1 ELSE no mapping 


Nature of 

address 

indicator: 


"national (significant) 
number" 


hi-targeted-to-uri 


Add CC (of the country where the 

IVIGCF is located) to Generic 

Number Address Signals then map 

to user portion of URI scheme used. 

Addr-spec 

"+" CC NDC SN mapped to user 

portion of URI scheme used 


"international number" 


Map complete Redirection number 
Address Signals to user portion of 
URI scheme used. 


Address 
Signals 


If NOA is "national 

(significant) number" \.her\ 

the format of the Address 

Signals is: 

NDC + SN 

If NOA is "international 

number" 

then the format of the 

Address Signals is: 

CC + NDC + SN 


hi-targeted-to-uri 


"-I-" CC NDC SN mapped to userinfo 
portion of URI scheme used 


Redirecting 
number 


APRI 


Privacy header field that 
corresponds to the 
penultimate hi-targeted-to-uri 
entry in the History-Info 
header 


Priv-value 


"presentation restricted' 


"history 


"presentation allowed' 


Privacy header field absent or 
"none" (NOTE 3) 


Redirection 
Information 


Redirecting indicator 


Privacy header field that 
corresponds to the 
penultimate hi-targeted-to-uri 
entry in the History-Info 
header 


Priv-value 


Call diverted 


"none" (NOTE 4) 


Call diverted, all redirection 
info presentation restricted 


"history 


Redirection 
Information 


Redirection counter 

1 


hi-index 


Number of diversions are sown due 
to the number of hi-index Entries 
Index for original called Party 
Number = 1 

Address Signals (CdPN) 
Number = 1.1 


2 


Index for original called Party 

Number = 1 

Index for Redirecting number 

with Index =1.1 

Address Signals (CdPN) 

Number = 1.1.1 


N 


Index for original called Party 
Number = 1 

Placeholder History entry with Index 
= 1.1 

Fill up 

Index for Redirecting Number 
with = U[{N-1)*".1"] 
Index for Address Signals (CdPN) 
= UN*".1"(e.g. N=3-^ 1.1.1.1) 


Redirection 
Information 


Redirecting Reason and 
Original Redirection 
Reason 

(N0TE1) 


hi-targeted-to-uri; cause- 

param URI parameter, as 

defined in IETF RFC 4458 

[113]. 

The Redirecting Reason shall 


cause-param value 


unl<nown 


404 
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ISUP 

Parameter 

or IE 


Derived value of parameter 
field 


SIP component 


Value 




unconditional 


be mapped to the last hi- 

targeted-to-uri. 

If the redirection counter is 2 

or higher, the Original 

Redirection Reason shall be 

mapped to the second hi- 

targeted-to-uri. 

If the redirection counter is 3 

or higher, for each hi-targeted- 

to-uri following a placeholder 

History entry the value "404" 

shall be taken (NOTE 2) 


302 


User Busy 


486 


No reply 


408 


Deflection during alerting 


487 


Deflection immediate 
response 


480 


Mobile subscriber not 
reachable 


503 


Called Party 
Number 


See Redirecting number 


History-Info header field see 
hi-targeted-to-uri 


URI of the last hi-targeted-to-uri 
entry of History-Info header field 


Original 
Called Party 
Number 


See Redirecting number 


History-Info header field see 
hi-targeted-to-uri 


URI of first hi-targeted-to-uri entry of 
History-Info header field 


Original 
Called Party 
Number 


APRI 


Privacy header field of the first 
hi-targeted-to-uri entry of 
History-Info header 


Priv-value 


"presentation restricted' 


"history 


"presentation allowed' 


"none" 


NOTE 1 : Original Redirection Reason contains only the "unknown" parameter 

NOTE 2: For all History entries except the first one a cause-param URI parameter as defined in IETF RFC 4458 

[113] has to be included. 
NOTE 3: If the Redirecting Indicator has the value "Call diverted, all redirection info presentation restricted', the 

privacy value "historf shall be set. 
NOTE 4: If the Redirecting Number APR! has the value "presentation restricted', the privacy value "history" shall 

be set. 



7.5.4.3 Interworking at the l-MGCF 

Table 7.5.4.3.1 : Mapping of SIP to ISUP messages 



-^Message received from SIP 


^Message send to BICC/ISUP 


INVITE request 


lAM 
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Table 7.5.4.3.2: Mapping of History-Info header field to ISUP Redirecting number 



Source SIP header field 
and component 


Source 

Component 

value 


Redirecting number 


Derived value of parameter field 


In History-Info SIP header 
field, hi-targeted-to-uri in hi- 
entry before last hi-entry 
containing a cause-param 
URI parameter, as defined 
in IETF RFC 4458 
[1 13]. (NOTE 1) 




Redirecting number 




hi-targeted-to-uri 
appropriate global number 
portion of the URI, 
assumed to be in form 
"+" CC -1- NDC -1- SN 


CC 


Nature of address indicator 


If CC is equal to the country code of the 
country where MGCF is located AND 
the next ISUP node is located in the 
same country, then set to "nationai 
(significant) numbei" else set to 
"internationai numbei" 


CC, NDC, SN 


Address signals 


If NOA is "national (significant) number" 

then set to 

NDC-i-SN. 

If NOA is "international numbei" 

then set to CC + NDC + SN 


Privacy header field, 
priv-value component 
in History-Info header field 
as specified in this table 
(NOTE 2) 


"history or 
"session" or 
"headei" 


APRI 


"presentation restricted' 


Privacy 
header field 
absent or 
"none" 


"presentation allowed' 


NOTE 1 : If it is SIP URI and doesn"t contain "user=phone", mapping to redirecting number is impossible, 

therefore no need to generate Redirecting number 
NOTE 2: It is possible that an entry of the History-Info header field itself is marked as restricted or the whole 

History-Info header. 
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Table 7.5.4.3.3: Mapping of History-info hieader to iSUP Redirection information 



Source SIP header field 
and component 


Source Component 
value 


Redirection 
Information 


Derived value of parameter field 


Privacy header field and 
priv-value of hi-entry before 
the last hi-entry containing 
acause-param URI 
parameter as defined in 
IETF RFC 4458 [113] of the 
History-Info header field. 


"historf or "session" or 
"headei" 

for the Privacy header 
field or for the hi- 
targeted-to-uri entry 


Redirecting 
indicator 


Cali diverted, ail redirection info 
presentation restricted 


Privacy header field 
and the privacy 
component of the hi- 
targeted-to-uri entry 
either absent 
or 
"none" 


Cali diverted 






Original 
redirection reason 


Unl<nown 


Cause-param value in the 
last hi-targeted-to-uri 
containing a cause-param 
as defined in IETF RFC 
4458 [11 3] 


cause-param value 


Redirecting 
Reason 


Redirecting Reason 


404 


Unl<nown/not available 


302 


Unconditional 


486 


User busy 


408 


No reply 


480 


Deflection immediate response 


487 


Deflection during alerting 


503 


Mobile subscriber not reachable 


Hi-index 




Redirection 
counter 


number of History entries containing a 
cause-param with value as listed in the 
cause-param row in this table (NOTE) 


NOTE: If the determined number of redirection in SIP exceeds the ISUP maximum parameter value, the MGCF 
shall set the Redirection counter to its maximum value. For instance, in ISUP ITU-T Q.763 [4], the 
Redirection counter parameter cannot exceed 5. 



Table 7.5.4.3.4: iVIapping of IHistory-lnfo hieader field to ISUP Original Called number 



Source SIP header field 
and component 


Source 

Component 

value 


Original called number 


Derived value of parameter field 






Numbering Plan Indicator 


"ISDN (Telephony) numbering plan 
(Recommendation E. 164)" 


hi-targeted-to-uri of hi-entry 
preceding the 1^' hi- 
targeted-to-uri containing a 
cause-param URI 
parameter, as defined in 
IETF RFC 4458 [113]; the 
global number portion of 
the URI, is assumed to be 
in form 

"+" CC + NDC -1- SN 
(N0TE1) 


CC 


Nature of address indicator 


If CC is equal to the country code of the 
country where MGCF is located AND 
the next ISUP node is located in the 
same country, then set to "national 
(significant) numbei" else set to 
"international numbei" 


CC, NDC, SN 


Address signals 


If NOA is "national (significant) numbei" 

then set to 

NDC-i-SN. 

If NOA is "international numbei" 

then set to CC + NDC -i- SN 


priv-value component 
in History-Info header field 
of the History-Info header 
field entry as defined above 
in this table (NOTE 2) 


"history or 
"session" or 
"headei" 


APRI 


"presentation restricted' 


Privacy 
header field 
absent or 
"none" 




"presentation allowed' 


NOTE 1 : If it is SIP URI and doesn"t contain " user=phone" , mapping to Original Called number is impossible, 

therefore no need to generate Original Called number 
NOTE 2: It is possible that an entry of the History-Info header field itself is marked as restricted or the whole 

History-Info header. 
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Table 7.5.4.3.5: Mapping of INVITE to lAM 



INVITE 




lAM 




History-Info header 
field 


See table 7.5.4.3.2 


Redirecting 
number 


See table 7.5.4.3.2 


History-Info header 
field 


See table 7.5.4.3.3 


Redirection 
Information 


See table 7.5.4.3.3 


cause-param in the 
last hi-targeted-to-uri 
containing a cause- 
param as defined in 
IETF RFC 4458 [11 3] 


cause-param value 


Redirection 
Information 


Redirecting Reason 


404 


Unknown/not available 


302 


Unconditional 


486 


User busy 


408 


No reply 


480 


Deflection immediate response 


487 


Deflection during alerting 


503 


Mobile subscriber not reactiable 


History-Info header 
field 


See table 7.5.4.3.4 


Original Called 
Number 


See table 7.5.4.3.4 



Table 7.5.4.3.6: IVIapping of ISUP to SIP IVIessages 



^-Message sent to SIP 


^-Message Received from BICC/ISUP 




181 (Being forwarded) 


ACIVI no indication with Redirection number and call 
diversion information (CFU, CFB, CD!) 


See table 7.5.4.3.8 


180 (Ringing) 


ACIVI indicating ringing, oBCi: Call diversion may 
occur (CFNR, CDa) 


See subclause 7.2.3.1 .4 


181 (Being forwarded) 


CPG indicating progress or subsequent diversion 
indicated in the CPG with Redirection number and 
call diversion information (CFNR, CDa) 


See table 7.5.4.3.9 


180 (Ringing) 


CPG indicating ringing and Redirection number 
restriction parameter 


See table 7.5.4.3.10 


200 (OK) 


ANM and Redirection number restriction parameter 


See table 7.5.4.3.11 



Table 7.5.4.3.7: Mapping of ISUP Redirection Number Restriction to History-Info header field 



Redirection Number 
Restriction 


Derived value of parameter field 


SIP component 


Value 


Presentation restricted 
indicator 


"Presentation restricted' 




"History 


"Presentation allowed' or absent AND any previous 
received notification subscription option was NOT 
"presentation not allowed' AND was NOT 
"presentation allowed without redirection number" 




Privacy header 
field absent 
or 
"none" 
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Table 7.5.4.3.8: Mapping of ACM -> 181 (Call Is Being Forwarded) response 



ISUP Parameter 


Derived value of 
parameter field 


SIP component 


Value 


Generic notification 
indicators 


Call is diverting 






Redirection number 




History-Info header field with 
one hi-entry 


hi-targeted-to-uri: 


Nature of address 
indicator: 


"national (significant) 
number" 


hi-targeted-to-uri 


Add CC (of the country where 

the IVIGCF is located) to 

Redirection number Address 

Signals then map to user 

portion of URI scheme used. 

Addr-spec 

"+" CC NDC SN mapped to 

user portion of URI scheme 

used 

according to the rules of 

3GPP TS 24.604 [60] 

subclause 4.5.2.6.4 item c 




"international number" 




Map complete Redirection 

number Address Signals to 

user portion of URI scheme 

used 

according to the rules of 

3GPP TS 24.604 [60] 

subclause 4.5.2.6.4 item c 


Address Signals 


If NOA is "national 

(significant) numbei" then 

the format of the Address 

Signals is: 

NDC + SN 

If NOA is "international 

number" 

then the format of the 

Address Signals is: 

CC + NDC + SN 


hi-targeted-to-uri 


"+" CC NDC SN mapped to 
userinfo portion of URI 
scheme used 


Call diversion 
information 


Redirecting Reason 


IETF RFC 4458 [113] cause- 
param URI parameter in the 
hi- targeted-to-uri (NOTE) 


cause-param value 


Unknown/not available 


404 


Unconditional 


302 


User busy 


486 


No reply 


408 


Deflection immediate 
response 


480 


Deflection during alerting 


487 


Mobile subscriber not 
reachiable 


503 


Notification subscription 
option 


Privacy (NOTE) 


Roles 


unknown 


Escaped Privacy value is set 
according to the rules of 
3GPP TS 24.604 [60] 
subclause 4.5.2.6.4 item c 


presentation not allowed 


A 181 Being Forwarded shall 
not be sent 


presentation allowed witti 
redirection number 


Escaped Privacy value is set 
according to the rules of 
3GPP TS 24.604 [60] 
subclause 4.5.2.6.4 item c 


presentation allowed 
without redirection number 


Escaped Privacy value is set 
according to the rules of 
3GPP TS 24.604 [60] 
subclause 4.5.2.6.4 item c 


NOTE: Needs to be stored for a possible inclusion into subsequent messages. | 
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Table 7.5.4.3.9: Mapping of CPG -^181 (Call Is Being Forwarded) response 



ISUP Parameter 


Derived value of parameter 
field 


SIP component 


Value 


Event Indicator 


Progress 






Generic notification 
indicators 


Call is diverting 






Redirection number 




History-Info header field with 
one hi-entry 


hi-targeted-to-uri: 


Nature of address 
indicator 


"national (significant) 
number" 


hi-targeted-to-uri 


Add CC (of the country where 

the IVIGCF is located) to 

Redirection number Address 

Signals then map to user 

portion of URI scheme used. 

Addr-spec 

"+" CC NDC SN mapped to 

user portion of URI scheme 

used 

according to the rules of 

3GPP TS 24.604 [60] 

subclause 4.5.2.6.4 items c 




"international number" 


hi-targeted-to-uri 


IVIap complete Redirection 

number Address Signals to 

user portion of URI scheme 

used 

according to the rules of 

3GPP TS 24.604 [60] 

subclause 4.5.2.6.4 items c 


Address Signals 


If NOA is "national 

(significant) numbei" then 

the format of the Address 

Signals is: 

NDC + SN 

If NOA is "international 

number" 

then the format of the 

Address Signals is: 

CC + NDC + SN 


hi-targeted-to-uri 


"+" CC NDC SN mapped to 
userinfo portion of URI 
scheme used 


Call diversion 
information 


Redirecting Reason 


IETF RFC 4458 [113] cause- 
param URI parameter in the 
hi- targeted-to-uri (NOTE) 


cause-param value 


Unknown/not available 


404 


Unconditional 


302 


User busy 


486 


No reply 


408 


Deflection immediate 
response 


480 


Deflection during alerting 


487 


Mobile subscriber not 
reaciiabie 


503 


Notification subscription 
option 


Privacy (NOTE) 


Roles 


unknown 


Escaped Privacy value is set 
according to the rules of 
3GPP TS 24.604 [60] 
subclause 4.5.2.6.4 items c 


presentation not allowed 


A 181 Being Forwarded shall 
not be sent 


presentation allowed witii 
redirection number 


Escaped Privacy value is set 
according to the rules of 
3GPP TS 24.604 [60] 
subclause 4.5.2.6.4 items c 


presentation allowed witiiout 
redirection number 


Escaped Privacy value is set 
according to the rules of 
3GPP TS 24.604 [60] 
subclause 4.5.2.6.4 items c 


NOTE: Needs to be stored for a possible inclusion into subsequent messages. | 
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Table 7.5.4.3.10 addresses two separate conditions: the CPG is received from the diverting exchange in which case the 
Call diversion information is included; and the CPG is received from the diverted-to exchange in which case the Call 
diversion information is not included. Interworking for both conditions is shown. 

Table 7.5.4.3.10: Mapping of CPG ^ 180 (Ringing) response 



ISUP Parameter 


Derived value of 
parameter field 


SIP component 


Value 


Event Indicator 


Alerting 






Redirection number 




History-Info header field with 
one hi-entry 


See table 7.5.4.3.8 


Call diversion information 


Redirecting Reason 


IETF RFC 4458 [113] cause- 
param URI parameter in the 
hi- targeted-to-uri (NOTE) 


cause-param value 


Unknown/not available 


404 


Unconditional 


302 


User busy 


486 


No reply 


408 


Deflection immediate 
response 


480 


Deflection during 
alerting 


487 


Mobile subscriber not 
reachable 


503 


Notification 
subscription option 


Privacy (NOTE) 


Roles 


unknown 


Escaped Privacy value is set 
according to the rules of 
3GPP TS 24.604 [60] 
subclause 4.5.2.6.4 item c 


presentation not 
allowed 


The 180 Ringing response 
shall be sent without the the 
History-Info header field 
included 


presentation allowed 
with redirection number 


Escaped Privacy value is set 
according to the rules of 
3GPP TS 24.604 [60] 
subclause 4.5.2.6.4 item c 


presentation allowed 
without redirection 
number 


Escaped Privacy value is set 
according to the rules of 
3GPP TS 24.604 [60] 
subclause 4.5.2.6.4 item c 


If no Call diversion 
information parameter is 
present 




IETF RFC 4458 [113] cause- 
param URI parameter in the 
hi- targeted-to-uri 


Value stored from a previous 
received ACIVI or CPG. See 
tables 7.5.4.3.8 and 
7.5.4.3.9. 


Privacy 


Value stored from a previous 
received ACIVI or CPG. See 
tables 7.5.4.3.8 and 
7.5.4.3.9. 


Redirection number 
restriction 






See table 7.5.4.3.7 


NOTE: Needs to be stored for a possible inclusion into subsequent messages. 
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Table 7.5.4.3.11 : Mapping of ANM -> 200 (OK) response (to INVITE request) 



ISUP Parameter 


Derived value of 
parameter field 


SIP component 


Value 


Redirection number 




History-Info header field with 
one hi-entry 


See table 7.5.4.3.8 






IETF RFC 4458 [113] cause- 
param URI parameter in the 
hi- targeted-to-uri 


cause value= as stored from 
a previous received ACM or 
CPG. See tables 7.5.4.3.8 
and 7.5.4.3.9. 


Redirection number 
restriction 






See table 7.5.4.3.7 



7.5.5 Communication Hold (HOLD) 



The mapping of Communication Hold supplementary service with Call Hold PSTN/ISDN Supplementary Service is the 
same mapping as described in subclause 7.4.10. The Service itself is described within 3GPP TS 24.610 [65]. 



7.5.6 Conference call (CONF) 



7.5.6.1 



General 



The protocol description of the CONF supplementary service is described in 3GPP TS 24.605 [61]. In this subclause the 
interworking from the conference event package RFC 4575 [100] to the messages of the PSTN/ISDN CONF 
supplementary service is described. Note that an interworking from the PSTN/ISDN to the IMS is out of scope. 

7.5.6.2 Subscribing for the conference event package 

Based on local policy, the MGCF may subscribe for the conference event package on behalf of the PSTN/ISDN 
participant after the participant joins or is added to a conference. 

When the conference event package option is implemented, and one of the following events occurs at the MGCF: 

a 200 (OK) response is received as a response to an initial INVITE request originated by the MGCF, where the 
Contact header field contains an "isfocus" parameter; or 

an ACK message is received which acknowledges a 200 (OK) response to the initial INVITE request, and the 
initial INVITE request is originated by the conferencing AS and contains an "isfocus" parameter in the Contact 
header field; 

then the following steps shall be performed: 

1) a SUBSCRIBE request shall be created according to RFC 4575 [100]; 

2) the Request URI is set to the Contact address of the conferencing AS; 

3) the P-Asserted-Identity header field, the From header field and the Privacy header field are set with the same 
value as: 

the P-Asserted-Identity header field, the From header field and the Privacy header field in the initial INVITE 
request originated by the MGCF; or 

the P-Asserted-Identity header field, the To header field and the Privacy header field in a Ixx or 2xx response 
sent by the MGCF to the initial INVITE request from the conferencing AS. 



7.5.6.3 



Interworking the notification 



NOTE: There is a need to differentiate between the procedures of interworking for a full and a partial type of 
notification. 
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When a full type of notification is received a check is made of the content. If the changes with respect a previous 
version of the notification have not been sent on to the PSTN/ISDN for this session, the MGCF shall perform an ISUP 
interaction towards the PSTN/ISDN. If the changes with respect a previous version of the notification have been sent to 
the PSTN/ISDN for this session, the MGCF shall not perform an ISUP interaction towards the PSTN/ISDN. 

When a partial notification is received then it is assumed that a value of a received notification has changed, so the 
MGCF performs an ISUP interaction towards the PSTN/ISDN, as follows: 

Conference established: 

Upon the receipt of a conference information document with the <conference-state-type> element active is set to 
"true", the MGCF shall send a CPG message to the PSTN/ISDN with a notification "conference established". 

Participant added: 

Upon the receipt of a conference information document with the <endpoint-type> and the element status of 
endpoint-status-type is set to "connected" and it was not set to "on-hold" before and the Contact URI in the 
element entity is not the address of the served PSTN/ISDN participant, the MGCF shall send a CPG message to 
the PSTN/ISDN with a notification "other party added". 

- Served PSTN/ISDN participant isolated: 

Upon the receipt of a conference information document with the <endpoint-type> and the element status of 
endpoint-status-type is set to "on-hold" and it was set to "connected" before and the Contact URI in the element 
entity is the address of the served PSTN/ISDN participant, the MGCF shall send a CPG message to the 
PSTN/ISDN with a notification "isolated". 

Other participant isolated: 

Upon the receipt of a conference information document with the <endpoint-type> and the element status of 
endpoint-status-type is set to "on-hold" and it was set to "connected" before and the Contact URI in the element 
entity is not the address of the served PSTN/ISDN participant, the MGCF shall send a CPG message to the 
PSTN/ISDN with a notification "other party isolated" . 

- Served PSTN/ISDN participant reattached: 

Upon the receipt of a conference information document with the <endpoint-type> and the element status of 
endpoint-status-type is set to "connected" and it was set to "on-hold" before and the Contact URI in the element 
entity is the address of the served PSTN/ISDN participant, the MGCF shall send a CPG message to the 
PSTN/ISDN with a notification "reattached". 

- Other participant reattached: 

Upon the receipt of a conference information document with the <endpoint-type> and the element status of 
endpoint-status-type is set to "connected" and it was set to "on-hold" before and the Contact URI in the element 
entity is not the address of the served PSTN/ISDN participant, the MGCF shall send a CPG message to the 
PSTN/ISDN with a notification "other party reattached" . 

Other party disconnected: 

Upon the receipt of a conference information document with the <endpoint-type> and the element status of 
endpoint-status-type is set to "disconnected" and the element joining-method of joining-type is not set to "focus- 
owner", the MGCF shall send a CPG message to the PSTN/ISDN with a notification "other party disconnected" . 

7.5.7 Anonymous Communication Rejection (ACR) and Communication 
Barring (CB) 

The Anonymous Communication rejection (ACR) and Communication Barring (CB) services are described within 
3GPPTS 24.611 [67]. 

The mapping of Anonymus Communication Rejection supplementary service with Anonymus Call Rejection 
PSTN/ISDN Supplementary Service is described in subclause 7.4.23. 
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The mapping for Communication Barring is in accordance with the basic call procedures as described in subclauses 
7.2.3.1.8 and 7.2.3.2.12. 

7.5.8 Message Waiting Indication (MWI) 

The Message Waiting Indication supplementary service is described within 3GPP TS 24.606[62]. 

7.5.9 Malicious Communication Identification (MCID) 



7.5.9.0 



General 



The protocol specification of the Malicious Communication Identification supplementary service is described in 3GPP 
TS 24.616 [102]. The XML MCID body used in related SIP messages is also specified in 3GPP TS 24.616 [102]. 



7.5.9.1 



Interworking at the 0-MGCF 



7.5.9.1.0 



General 



If the MGCF supports the interworking of the MCID service the O-MGCF shall map a SIP INFO request containing a 
XML mcid body with MCID XML Request schema to an Identification Request (IDR) message and an Identification 
response (IRS) message to a SIP INFO request containing a XML mcid body with MCID XML Response schema in 
accordance with table 7.5.9.1.1. 

The IDR message shall be generated upon reception of the SIP INFO request containing a XML mcid body with MCID 
XML Request schema. 

The SIP INFO request containing a XML mcid body with MCID XML Response schema shall be generated upon 
reception of the IRS message. 

Table 7.5.9.1.1 Mapping between ISUP IDR and IRS and SIP messages 



ISUP Message 


SIP Message 


IDR 


INFO containing a XIVIL mcid body with IVICID XML Request schema 


IRS 


INFO containing a XIVIL mcid body with IVICID XML Response schema 



7.5.9.1.1 



Interworking of the MCID XML Request schema with the ISUP MCID request 
indicators 



If the MGCF supports the interworking of the MCID service O-MGCF shall map the codes in the MCID XML elements 
to MCID request indicator and holding indicator parameter fields in accordance with table 7.5.9.1.1.1. 

Table 7.5.9.1.1.1 Mapping between ISUP MCID request and holding indicators and MCID XML 

elements 



7.5.9.1.2 



ISUP Parameter 


XML Element 


bit A: 


MCID request indicator 


McidRequestlndicator 





MCID not requested 


type=0 


1 


MCID requested 


type=1 








bit B: 


Holding indicator (national use) 


Holdinglndicator 





holding not requested 


type=0 


1 


holding requested 


type=1 



Interworking of the ISUP MCID response indicators with the MCID XML 
Response schema 



If the MGCF supports the interworking of the MCID service the O-MGCF shall map the codes in the MCID response 
indicator and hold provided indicator parameter field to the MCID XML elements in accordance with table 7.5.9. 1 .2. 1 . 
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Table 7.5.9.1.2.1 Mapping between ISUP MCID response and hold provided indicators and MCID XML 

elements 



ISUP Parameter 


XML Element 


bit A: 


IVICID response indicator 


McidResponselndicator 





IVICID not included 


type=0 


1 


IVICID included 


type=1 








bit B: 


Hold provided indicator (national use) 


HoldingProvidedlndicator 





holding not provided 


type=0 


1 


holding provided 


type=1 



7.5.9.1.3 



Interworking of the ISUP Calling Party Number in an Identification Response with 
the OrigPartyldentity within the MCID XML Response schema 



If the O-MGCF supports the interworking of the MCID service and receives an ISUP Identification Response 
containing a Calling Party Number with the screening indicator set to "user provided, verified and passed" or "network 
provided", the O-MGCF shall map the Calling Party Number to the MCID XML Response schema OrigPartyldentity 
element applying the same mapping procedures as described in table 14 for the mapping into the SIP P-Asserted- 
Identity header and shall map the Calling Party Number APRI to the MCID XML Response schema 
OrigPartyPresentationRestriction element. If the Calling Party Number APRI has a value of "presentation allowed" then 
the MCID XML Response schema OrigPartyPresentationRestriction element shall be set to "false", otherwise it shall be 
set to "true". 

7.5.9.1 .4 Interworking of the ISUP Generic Number in an Identification Response with the 

GenericNumber within the MCID XML Response schema 

If the O-MGCF supports the interworking of the MCID service and receives an ISUP Identification Response 
containing a Generic Number with the screening indicator set to "user provided, verified and passed" , or "user 
provided, not verified", or "network provided" , the O-MGCF shall map the Generic Number to the MCID XML 
Response schema GenericNumber element applying the same mapping procedures as described in table 13 for the 
mapping into the SIP From header and shall map the Generic Number APRI to the MCID XML Response schema 
GenericNumberPresentationRestriction element. If the Generic Number APRI has a value of "presentation allowed" 
then the MCID XML Response schema GenericNumberPresentationRestriction element shall be set to "false", 
otherwise it shall be set to "true". 



7.5.9.2 



Interworking at the l-MGCF 



7.5.9.2.1 



General 



If the MGCF supports the interworking of the MCID service the I-MGCF shall map an Identification Request (IDR) 
message to a SIP INFO request containing a XML mcid body with MCID XML Request schema and a SIP INFO 
request containing a XML mcid body with MCID XML Response schema to an Identification response (IRS) message 
in accordance with table 7.5.9.1.1. 



7.5.9.2.2 



Interworking of identification Request 



The SIP INFO request containing a XML mcid body with MCID XML Request schema shall be generated upon 
reception of the IDR message. The I-MGCF shall map the codes in the MCID request indicator and holding indicator 
parameter fields to the MCID XML elements in accordance with table 7.5.9.1.1.1. 



7.5.9.2.3 



Interworking of identification Response 



The IRS message shall be generated upon reception of the SIP INFO request containing a XML mcid body with MCID 
XML Response schema. The I-MGCF shall map the codes in the MCID XML elements to the MCID response indicator 
and hold provided indicator parameter fields in accordance with table 7.5.9.1.2.1. 

If the received MCID XML Response schema contains an OrigPartyldentity element, the I-MGCF shall map the 
OrigPartyldentity to the Calling Party Number within the IRS applying the same mapping procedure as described in 
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table 5 for the mapping from the SIP P-Asserted-Identity header, with the exception that the I-MGCF shall map the 
MCID XML Response schema OrigPartyPresentationRestriction element to the Calling Party Number APRI. If the 
MCID XML Response schema OrigPartyPresentationRestriction element has the value "true", the Calling Party 
Number APRI shall be set to "presentation restricted", and otherwise the Calling Party Number APRI shall be set to 
"presentation allowed". 

If the received MCID XML Response schema contains an GenericNumber element, the I-MGCF shall map the 
GenericNumber to the Generic Number within the IRS applying the same mapping procedure as described in table 6 for 
the mapping from the From header, with the exception that the I-MGCF shall map the MCID XML Response schema 
GenericNumber PresentationRestriction element to the Generic Number APRI. If the MCID XML Response schema 
GenericNumberPresentationRestriction element has the value "true", the Generic Number APRI shall be set to 
"presentation restricted", and otherwise the Generic Number APRI shall be set to "presentation allowed". 

7.5.1 Closed User Group (CUG) 

7.5.10.0 General 

The protocol specification of the Closed User Group supplementary service is described in 3GPP TS 24.654 [101]. 

7.5.1 0.1 Interworking at the I-MGCF 

If the I-MGCF supports the interworking of CUG supplementary service, the I-MGCF shall map between the SIP and 
ISUP messages in accordance with table 7.5.10.1.1. 

Table 7.5.10.1.1 : Mapping of SIP messages to ISUP messages 



SIP Message 


ISUP Message 


INVITE request containing a XIVIL cug body with CUG 
XIVIL schema 


//A/W containing the Closed user group interlock code 

Parameter and the closed user group call indicator oi the 
Optional Forward Call Indicator Parameter 



If the MGCF supports the interworking of CUG supplementary service, the I-MGCF shall interwork the CUG XML 
schema with the ISUP Closed user group interlock code parameter and the Closed user group call indicator of the 
optional forward call indicator parameter in accordance with tables 7.5.10.1.2 and 7.5.10.1.3. 

Table 7.5.10.1.2: Mapping of the SIP XML CUG Element to the ISUP closed usergroup interlock code 

parameter 



CUG XML Element 


Source component 
value 


ISUP Closed user group 
interlock code Parameter 


derived value of parameter field 


networklndicator 


networkidentityType = 4 
hexbinary coded digits 
(NOTE) 


"Network Identity" 


Octet 1 & Octet 2 including 4 binary 
coded digits derived from XIVIL 
Network Identity 


cuglnterlockBinaryCode 


sixteenbitType = 1 6 bit 
coded value 


"Binary Code" 


Octet 3 & Octet 4 including a 16 bit 
Binary Code derived from the XML 
Binary Code 


NOTE: ISUP Closed user group interlock code Parameter Octet 1 contains "Network Identity" (Nl) digits 1 & 2 and 

Octet 2 contains "Network Identity" digits 3 & 4.The networkidentityType is filled with "Octetl & Octet 2" = "Nl 
digit 1, Nl digit 2, Nl digit 3, Nl digit 4". Example: Digit 1=0, Digit 2=4, Digit 3=9, Digit 4=0 so the 
networkidentityType is encoded with "0490". 
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Table 7.5.10.1.3: Mapping of the SIP XML CUG Element to the ISUP closed user group call indicator 
included in the optional Forward Call Indicator Parameter 



CUG XML Element 


Source component 
value 


ISUP "Optional Forward Call 
Indicator" Parameter 


derived value of parameter 
field 


cugCommunicationlndicator 


Type=00 


"closed user group calf 
indicator 


non-CUG call 




Type=01 


spare 




Type=10 


closed user group call, outgoing 
access allowed 




Type=1 1 


closed user group call, outgoing 
access not allowed 



If the I-MGCF supports the interworking of CUG supplementary service, then if an INVITE request with the MIME 
including a cug XML element is received and the terminating network is not supporting CUG, the I-MGCF shall behave 
as shown in table 7.5.10.1.4. 

Table 7.5.10.1.4: Action at the I-MGCF with a PSTN/ISDN network without CUG capability 



cugCommunicationlndicator in INVITE request 


Action at the I-MGCF 


Type=1 1 (CUG without outgoing access) 


Release the communication with 403 


Type=10 (CUG with outgoing access) 


Treat the communication as an ordinary call (NOTE) 


Non-CUG 


Treat the communication as an ordinary call 


NOTE: The cugCommunicationlndicator shall not be mapped or if appropriate the CUG call indicator of the optional 
forward call indicator shall be set to non-CUG call. 



7.5.1 0.2 Interworking at the 0-MGCF 

If the MGCP supports the interworking of CUG supplementary service, the O-MGCF shall map between the SIP and 
ISUP messages in accordance with table 7.5.10.2.1 

Table 7.5.10.2.1 : Mapping of ISUP messages to SIP messages 



ISUP Message 


SIP Message 


lAIVI containing the Closed user group interlock code Parameter and the 

closed user group call indicator of the Optional Forward Call Indicator Parameter 


INVITE request containing a XIVIL 
cug body with CUG XML schema 



If the MGCP supports the interworking of CUG supplementary service, the MGCP shall interwork the CUG XML 
schema with the ISUP Closed user group interlock code parameter and the Closed user group call indicator of the 
optional forward call indicator parameter in accordance with tables 7.5.10.2.2 and table 7.5.10.2.3. 

Table 7.5.10.2.2: Mapping of the ISUP closed usergroup interloccode to SIP XML CUG element 



ISUP Closed user group 
interlock code Parameter 


Source component value 


CUG XML Element 


derived value of 
parameter field 


"Network Identity" 


Octet 1 & Octet 2 including 4 
binary coded digits 


networklndicator 


networkidentityType = 4 
hexbinary coded digits 
derived from Network 
Identity (NOTE) 


"Binary Code" 


Octet 3 & Octet 4 including a 16 
bit Binary Code 


cuglnterlockBinaryCode 


sixteenbitType = 1 6 bit 
coded value derived from 
Binary Code 


NOTE: ISUP Closed user group interlock code Parameter Octet 1 contains "Network Identity" (Nl) digits 1 & 2 and 

Octet 2 contains "Network Identity" digits 3 & 4.The networkidentityType shall be filled with "Octetl & Octet 2" 
= "Nl digit 1 , Nl digit 2, Nl digit 3, Nl digit 4". Example: Digit 1 =0, Digit 2=4, Digit 3=9, Digit 4=0 so the 
networkidentityType is encoded with "0490". 
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Table 7.5.10.2.3: Mapping of the ISUP Closed user group call indicator to SIP XML CUG element 



ISUP Optional Forward Call 
Indicator Parameter 


Source component value 


CUG XML Element 


derived value of 
parameter field 


closed user group call indicator 


non-CUG call 


cugCommunicationlndicator 


Type=00 


spare 


Type=01 


closed user group call, outgoing 
access allowed 


Type=10 


closed user group call, outgoing 
access not allowed 


Type=1 1 



If the MGCF supports the interworking of CUG supplementary service, but the IMS is not supporting CUG, the 
procedures described in ITU Q.735. 1 [42] shall apply if an INVITE request with the MIME body including a cug XML 
element is sent and the O-MGCF supports CUG supplementary service. 

7.5.11 CCBS/CCNR 



7.5.11.0 



General 



The protocol specification of the Completion of Communications to Busy Subscriber and Completion of 
Communications by No Reply supplementary services is described in 3GPP TS 24.642 [1 12] 



7.5.11.1 



Interworking at the l-MGCF 



If the I-MGCF supports the interworking of CCBS/CCNR supplementary services, the I-MGCF shall map between the 
SIP and ISUP messages in accordance with table 7.5.11.1.1. 



Table 7.5.11.1.1: Mapping of ISUP and SIP messages 



SIP Message 


Parameter 


ISUP Message 


Parameter 


^ 180 Ringing 


Call-Info header field with purpose header 
field parameter set to "call-completion" 
and "m" header field parameter set to 
"NR" (no reply) 
(N0TE1) 


^ACM 


Called party's status indicator set to 

"Subscriber free" and 

CCNR possible indicator set to 

"CCNR possible" 

(NOTE 2) 


^ 180 Ringing 


Call-Info header field with purpose header 
field parameter set to "call-completion and 
"m" header field parameter set to "NR" (no 
reply) 
(N0TE1) 


^CPG 


Event indicator set to "Alerting" and 
CCNR possible indicator set to 
"CCNR possible" 
(NOTE 2) 


<- 486 Busy here 


Call-Info header field with purpose header 
field parameter set to "call-completion" 
and "m" header field parameter set to "BS" 
(busy subscriber) 
(N0TE1) 


^REL 


Cause Indicator 

cause #17 with Diagnostic (CCBS 
indicator set to "CCBS possible") 
(NOTE 3) 


-^ INVITE 


Request URI contains "m" SIP URI 
parameter or Call-Info header field 
contains "purpose" header field parameter 
set to "call-completion" and "m" header 
field parameter. 
(N0TE1) 


^lAM 


CCSS parameter set to "CCSS call" 
(NOTE 2) (NOTE 4) 


NOTE 1 : The coding shall be in accordance with IETF draft-ietf-bliss-call-completion [106]. 

NOTE 2: The coding shall be in accordance with ITU-T recommendation 0. 763 [4]. 

NOTE 3: The coding shall be in accordance with ITU-T recommendation Q. 850 [38]. 

NOTE 4: CCSS parameter set to the value "CCSS call" is included in the lAIVI if Request-URI contains the SIP URI 

parameter "m" i.e. creation of the CCSS parameter does not depend on the received value of the SIP URI 

parameter "m". 



If the I-MGCF supports the interworking of CCBS/CCNR supplementary services, the I-MGCF shall map between the 
SIP and TCAP messages in accordance with table 7.5.11.1.2 and table 7.5.11.1.3. 
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Table 7.5.1 1 .1 .2: Mapping of SIP messages to TCAP messages 



SIP Message 


Parameter 


TCAP Message 


Parameter 


SUBSCRIBE with m-parameter in Request URI set 
to "BS" or containing Call-Info header field with 
"purpose" parameter set to "call-completion" and 
m-parameter set to "BS" 
(N0TE1) 


Request URI 
(NOTE 5) 


TC-Begin CCBS 
REOUEST (invoke) 


CalledPartyNumber 
(NOTE 3) 


P-Asserted-ldentity 


CallingPartyNumber 
(NOTE 4) 




RetainSupported 
(NOTE 2) 


SUBSCRIBE with m-parameter in Request URI set 
to "NR" or containing Call-Info header field with 
"purpose" parameter set to "call-completion" and 
m-parameter set to "NR" 
(N0TE1) 


Request URI 
(NOTE 5) 


TC-Begin CCNR 
REOUEST (invoke) 


CalledPartyNumber 
(NOTE 3) 


P-Asserted-ldentity 


CallingPartyNumber 
(NOTE 4) 




RetainSupported 
(NOTE 2) 


PUBLISH with m-parameter in Request URI or m- 
parameter in Call-Info header field set to "BS" and 
body containing PIDF basic status set to "closed". 




TC-Cont CCBS 
SUSPEND 




PUBLISH with m-parameter in Request URI or m- 
parameter in Call-Info header field set to "BS" and 
body containing PIDF basic status set to "open". 




TC-Cont CCBS 
RESUME 




PUBLISH with m-parameter in Request URI or m- 
parameter in Call-Info header field set to "NR" and 
body containing PIDF basic status set to "closed". 




TC-Cont CCBS 
SUSPEND 




PUBLISH with m-parameter in Request URI or m- 
parameter in Call-Info header field set to "NR" and 
body containing PIDF basic status set to "open". 




TC-Cont CCBS 
RESUME 




SUBSCRIBE with m-parameter in Request URI or 
m-parameter in Call-Info header field set to "BS" 
and with Expires header set to "zero". 




TC-End CCBS 
CANCEL 




SUBSCRIBE with m-parameter in Request URI or 
m-parameter in Call-Info header field set to "NR" 
and with Expires header set to "zero". 




TC-End CCBS 
CANCEL 




NOTE 1 : Expires header defines subscription duration / CC service duration timer (CC-T3). 

NOTE 2: Parameter is set by default, as retention option is supported in IIVIS by default. 

NOTE 3: IVIapping of the Request URI header field to the CalledPartyNumber is done according to table 2 in 

subclause 7.2.3.1.2.1. 
NOTE 4: Mapping of the P-Asserted Identity header field to the CallingPartyNumber Is done according to table 5 in 

subclause 7.2.3.1.2.6. 
NOTE 5: If URI of the MGCF was returned in the Call-Info header field in the 1 80 Ringing or 486 Busy here messages 

described in table 7.5.1 1.1.1, then the MGCF needs to remember the Request URI of the original INVITE for 

mapping to the CalledPartyNumber. 



Table 7.5.11.1.3: Mapping of TCAP messages to SIP messages 



TCAP Message 


Parameter 


SIP Message 


Parameter 


TC-Cont CCBS REQUEST 
(return result) 


RetainSupported 


NOTIFY with cc-state parameter set to 
"queued" 


cc-service-retention 


TC-End CCBS/CCNR 
REOUEST (error result) 


ShortTermDenial 


480 Temporarily unavailable 




TC-End CCBS/CCNR 
REOUEST (error result) 


LongTermDenial 


403 Forbidden 




TC-End CCBS CANCEL 




NOTIFY with the "reason" Subscription-State 
header field parameter set to "noresource" 




TC-Cont REMOTE USER 
FREE 




NOTIFY with cc-state set to "ready" (NOTE 1) 




NOTE 1 : This does not terminate the subscribtion AS-AS. 



7.5.11.2 Interworking at the 0-MGCF 

If the O-MGCF supports the interworking of CCBS/CCNR supplementary services, the O-MGCF shall map between 
the ISUP and SIP messages in accordance with table 7.5.11.2.1. 
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Table 7.5.1 1 .2.1 : Mapping of SIP and ISUP messages 



ISUP Message 


Parameter 


SIP Message 


Parameter 


<-ACM 


Called party's status indicator set to 

"Subscriber free" and 

CCNR possible indicator set to "CCNR 

possible" 

(NOTE 2) 


^ 180 Ringing 


Call-Info header field with purpose 
header field parameter set to "call- 
completion" 
(N0TE1) 


<-CPG 


Event indicator set to "Alerting" and 

CCNR possible indicator set to "CCNR 

possible" 

(NOTE 2) (NOTE 4) 


^REL 


Cause Indicator 

cause #1 7 or #34 with Diagnostic (CCBS 
indicator set to "CCBS possible") 
(NOTE 3) 


^ 486 Busy here 


Call-Info header field with purpose 
header field parameter set to "call- 
completion" 
(NOTE 1) 


^lAM 


cess parameter set to "CCSS call" 
(NOTE 2) 


-> INVITE 


Request URI contains m-parameter 
and a Call-Info header field field, with 
purpose header field parameter set 
to "call-completion", and an m- 
parameter 
(N0TE1) (NOTES) 


NOTE 1 
NOTE 2 
NOTES 
NOTE 4 
NOTES 


The coding siiall be in accordance with IETF draft-ietf-bliss-call-completion [106]. 

The coding shall be in accordance with ITU-T recommendation 0. 763 [4]. 

The coding shall be in accordance with ITU-T recommendation Q. 8S0 [38]. 

A CPG will be sent if an ACM was already sent. 

Based on the operator policy the "m" SIP URI parameter in the Request-URI and m-parameter in Call-Info 

header field is set to the value "BS" or "NR". 



If the O-MGCF supports the interworking of CCBS/CCNR supplementary services, the O-MGCF shall map between 
the TCAP and SIP messages in accordance with table 7.5.1 1.2.2 and table 7.5.1 1.2.3. 
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Table 7.5.1 1 .2.2: Mapping of TCAP messages to SIP messages 



TCAP Message 


Parameter 


SIP Message 


Parameter 


TC-Begin CCBS 
REQUEST (invoke) 


CalledPartyNumber 


SUBSCRIBE with m-parameter in 
Request URI and m-parameter in Call- 
Info header field set to "BS" (NQTE 1) 


To header (NQTE 2) 


Request-URI (NQTE 2) 


CallingPartyNumber 


From header (NQTE 3) 


P-Asserted-ldentity (NQTE 4) 


TC-Begin CCNR 
REQUEST (invol<e) 


CalledPartyNumber 


SUBSCRIBE with m-parameter in 
Request URI and m-parameter in Call- 
Info header field set to "NR" (NQTE 1) 


To header (NQTE 2) 


Request-URI (NQTE 2) 


CallingPartyNumber 


From header (NQTE 3) 


P-Asserted-ldentity (NQTE 4) 


TC-Cont CCBS 
SUSPEND 




PUBLISH with m-parameter in Request 
URI and m-parameter in Call-Info header 
field set to "BS" and body containing 
PIDF basic status set to "closed". 




PUBLISH with m-parameter in Request 
URI and m-parameter in Call-Info header 
field set to "NR" and body containing 
PIDF basic status set to "closed". 




TC-Cont CCBS 
RESUME 




PUBLISH with m-parameter in Request 
URI and m-parameter in Call-Info header 
field set to "BS" and body containing 
PIDF basic status set to "open". 




PUBLISH with m-parameter in Request 
URI and m-parameter in Call-Info header 
field set to "NR" and body containing 
PIDF basic status set to "open". 




TC-End CCBS 
CANCEL 




SUBSCRIBE with m-parameter in 
Request URI and m-parameter in Call- 
Info header field set to "BS" and with 
Expires header set to "0" 




SUBSCRIBE with m-parameter in 
Request URI and m-parameter in Call- 
Info header field set to "NR" and with 
Expires header set to "0" 




NQTE 1 : Expires header defines subscription duration / CC service duration timer (CC-T3). 

NQTE 2: For the mapping of the CalledPartyNumber to the To header and Request-URI see table 1 0a in subclause 

7.2.3.2.2.1. 
NQTE 3: For the mapping of the CallingPartyNumber to the From header see table 1 5 in subclause 7.2.3.2.2.3 If no 

CallingPartyNumber is available, the From header shall be set to a SIP or SIPS URI with addr-spec of 

Unavailable User Identity as defined in 3GPP TS 23.003 [74]. 
NQTE 4: For the mapping of the CallingPartyNumber to the P-Asserted-ldentity header see table 14 in subclause 

7.2.3.2.2.3. If no CallingPartyNumber is available, a P-Asserted- Identity header shall not be inserted. 



Table 7.5.11.2.3: Mapping of SIP messages to TCAP messages 



SIP Message 


Parameter 


TCAP Message 


Parameter 


NQTIFY with cc-state parameter set 
to "queued" 


cc-service-retention 


TC Cont CCBS/CCNR 
REQUEST (return result) 


RetainSupported 


480 Temporarily unavailable 




TC-End CCBS/CCNR REQUEST 
(error result) 


ShortTerm Denial 


403 Forbidden 




TC-End CCBS/CCNR REQUEST 
(error result) 


LongTermDenial 


NQTIFY with the Subscription-State 
header field set to "terminated" and 
the "reason" parameter set to 
"noresource" 




TC-End CCBS CANCEL 




NQTIFY with cc-state set to "ready" 
(NQTE) 




TC-Cont REMQTE USER FREE 




NQTE: This does not terminate the subscription AS-AS. 
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7.5.12 Communication Waiting (CW) 



7.5.12.0 General 

The protocol specification of the Communication Waiting supplementary service is described in 3GPP TS 24.615 [111]. 



7.5.12.1 



Interworking at the l-MGCF 



With regard to the backward messages of the Call Waiting PSTN/ISDN supplementary service, the following mapping 
is valid: 

Table 7.5.12.1 : Mapping of ISUP messages to SIP Massages 



•^Message Received from BICC/ISUP 


^Message sent to SIP 


ACM or CPG with generic notification indicator "Call is 
a waiting call" (NOTE 1). 


1 80 Ringing with an Alert-Info header field set to 
"urn:alert:service:call-waiting" (NOTE 2). 


NOTE 1 : The coding shall be in accordance with ITU-T recommendation 0.733 [42]. 
NOTE 2: The coding shall be in accordance with IETF draft-salud-alert-info-urns [107]. 



7.5.1 2.2 Interworking at the 0-MGGF 

With regard to the backward messages of the Communication Waiting service, the following mapping is valid: 
Table 7.5.12.2: Mapping of SIP messages to ISUP messages 



^-Message sent to ISUP 


^-Message Received from SIP 


ACIVI or CPG with generic notification indicator "Call is 
a waiting call" (NOTE 1). 


1 80 Ringing with an Alert-Info header field set to 
"urn:alert:service:call-waiting" (NOTE 2). 


NOTE 1 : The coding shall be in accordance with ITU-T recommendation 0733 [42]. 
NOTE 2: The coding shall be in accordance with IETF draft-salud-alert-info-urns [107]. 



8 



User plane interworking 



8.1 Interworking between IM CN subsystem and bearer 
independent CS network 

When the IM CN subsystem interworks with the bearer independent CS networks (e.g. CS domain of a PLMN, 3GPP 
TS 29.414 [25], 3GPP TS 29.415 [26], 3GPP TS 23.205 [27]), the Transport Network Layer (TNL) of the bearer 
independent CS network can be based e.g. on IP/UDP/RTP, or IP/UDP/RTP/IuFP, or ATM/AAL2/ framing protocol 
(e.g. lu framing) transport techniques. Figure 31 shows the user plane protocol stacks for the IM CS subsystem and 
bearer independent CS network interworking. If the same AMR configuration is used on the CS network side as on the 
IMS side, transcoding is not required. However, there is still a need to interwork between RTP/UDP/IP/L2/LI to 
TNL/LI. 
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Figure 31/1 : IM CN subsystem to bearer independent CS network user plane protocol stack 

8.1 .1 Transcoder-less Mb to Nb Interworking 
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Figure 31/2: IM CN subsystem to bearer independent CS network user plane protocol stack (optional 

in the event the codecs on both sides are the same) 

If no transcoder is inserted, the IM-MGW shall interwork the following procedures between the Nb and Mb interfaces. 

8.1.1.1 Initialisation 

There is no need to interwork initialisation procedures between Nb and Mb interfaces see 3GPP TS 29.415 [26]. 



8.1.1.2 



Time alignment 



The purpose of the time alignment procedure on the Nb interface is to minimise the buffer delay in the RNC for 
downlink transmissions by adjusting the vocoder time reference within the network. No such procedure exists on the 
Mb interface, so the IM-MGW shall return NACK indication time alignment not supported according to 3GPP TS 
29.415 [26]. 
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8.1.1.3 



Rate control 



The rate control procedure signals to the peer entity the maximum rate among the currently allowed rates at which it can 
receive codec frames. Rate control only applies to AMR family codec configurations with multiple active modes. On 
the Nb interface, luFP provides for rate control via the exchange of RATE CONTROL and RATE CONTROL ACK 
PDUs. On the Mb interface, IETF RFC 4867 [23] provides for in-band rate control via the Codec Mode Request (CMR) 
field of every codec frame. 

Interworking of rate control procedures at an IM-MGW between an Mb interface and a corresponding Nb interface only 
applies when the IM-MGW bridges compatible codec configurations between the interfaces without applying a 
transcoding function. An IM-MGW receiving a CMR from an Mb interface shall initiate the luFP rate control procedure 
on the corresponding Nb interface. An IM-MGW receiving a rate control request on an Nb interface shall adjust the 
CMR field of outgoing speech frames on the corresponding Mb interface. 



8.1.1.4 



Frame quality indication 



The Nb interface signals frame quality with the Frame Quality Classification (FQC) field of each speech frame PDU. 
See 3GPP TS 26.102 [50] and 3GPP TS 29.415 [26] for details. The FQC may have possible values: O=frame_good; 
l=frame_bad; 2=frame_bad_due_to_radio; and 3=spare. The Mb interface signals frame quality with the Q bit (frame 
quality indicator) field of each speech frame, as defined in IETF RFC 4867 [23]. The Q bit may have values: 
l=speech_good; and 0=speech_bad or sid_bad. 

Tables 24a and 24b provide the mapping between Mb and Nb interfaces. 

Table 24a: Mapping of Mb (Q bit) onto Nb (FQC) 



Mb - Qbit 


Mb -FT 


Nb - FQC 


1 


X 








X 


1 



Table 24b: Mapping Nb onto Mb 



Nb - FQC 


Mb - Qbit 


Mb -FT 





1 


NC 


1 





NO DATA 


2 





NC 



8.1.1.5 



Framing 



Even when the IM-MGW bridges compatible codec configurations between the Nb and Mb interfaces, the IM-MGW 
shall perform translation between the frame formats defined for the two interfaces, since all codec configurations have 
different framing procedures for the two interfaces. The framing details for Nb are defined in 3GPP TS 26.102 [50] and 
3GPP TS 29.415 [26], although they do not describe the framing for ITU-T codecs other than G.71 1. The framing 
details for Mb are defined in IETF RFC 4867 [23], IETF RFC 3550 [51], IETF RFC 3551 [52] and IETF RFC 3555 
[53]. 



8.1.1.6 



Transcoding 



Transcoding at the IM-MGW is avoided when the IM-MGW bridges compatible codec configurations between the Nb 
and Mb interfaces. Otherwise transcoding is necessary, which eliminates the need to interwork other user plane 
procedures between the interfaces. 



8.1.1.7 



Discontinuous transmission 



When the IM-MGW bridges compatible codec configurations between the Nb and Mb interfaces, the DTX procedures 
are normally interworked transparently by translating between the framing formats on the interfaces. All the ITU-T and 
AMR family codecs have configurations that are compatible between the Mb and Nb interfaces. 
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8.1.1.8 



Timing and sequence information 



The IM-MGW shall always correct out-of-sequence delivery between Nb and Mb interfaces, either by re-ordering 
frames, or by dropping frames that are out of sequence. 

When the luFP frame numbers are based on time and if the IM-MGW bridges compatible codec configurations between 
the Nb and Mb interfaces, it shall either correct jitter before forwarding PDUs or interwork the RTP timestamp (see 
RFC 3550 [51]) with the luFP Frame Number (see 3GPP TS 29.415 [26]) so that both the RTP timestamp and luFP 
frame number similarly reflect the nominal sampling instant of the user data in the packet. 

NOTE: Correcting jitter may cause additional delay. 

The RTP sequence number (see RFC 3550 [51]) is handled independently on Mb, i.e. it is not interworked with the 
luFP Frame Number (see 3GPP TS 29.415 [26]). 

8.2 Interworking between IM CN subsystem and TDM-based 
CS network 



It shall be possible for the IM CN subsystem to interwork with the TDM based CS networks (e.g. PSTN, ISDN or CS 
domain of a PLMN). Figure 32 describes the user plane protocol stack to provide the particular interworking. 
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Figure 32: IM CN subsystem to TDM-based CS network user plane protocol stack 



8.3 Transcoding requirements 



The IM CN subsystem supports the AMR codec as the native codec for basic voice services. For IM CN subsystem 
terminations, the IM MGW shall support the transport of AMR over RTP according to IETF RFC 4867 [23]. The 
MGCF shall support the options of IETF RFC 4867 [23] Hsted within subclause 5.1.1 of 3GPP TS 26.236 [32]. 

It shall be possible for the IM CN subsystem to interwork with the CS networks (e.g. PSTN, ISDN or a CS domain of a 
PLMN) by supporting AMR to G.711 transcoding (see ITU-T Recommendation G.71 1 [1]) in the IM-MGW. The IM- 
MGW may also perform transcoding between AMR and other codec types supported by CS networks. 

8.4 Diffserv code point requirements 

The IM-MGW shall perform DiffServ Code Point (DSCP) markings (see RFC 2474 [21]) on the IP packets sent 
towards the IM CN subsystem entity like UE or MRFP across the Mb interface to allow DiffServ compliant routers and 
GGSNs to schedule the traffic accordingly. 
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The IETF Differentiated Services architecture (see RFC 2475 [22]) shall be used to provide QoS for the external bearer 

service. 

The DSCP shall be operator configurable. 

8.5 DTMF handling 

When sending DTMF inband towards the CS network, the MGW shall comply with the encoding requirements in 3GPP 
TS 23.014 [103]; in particular the requirements for the minimum length of a tone and for the minimum gap between two 
subsequent tones shall be ensured. 

When detecting DTMF digits arriving from the CS side, the MGW shall comply with TS 23.014 [103] (by checking that 
a valid digit with minimum duration and minimum gap has been received) before initiating an RTF Telephony Event to 
the IMS interface. 

When sending DTMF towards the IMS side according to the IETF RFC 4733 [105] RTF Fayload format, the MGW 
shall comply with the DTMF encoding requirements of Annex G.2 of 3GFF TS 26. 1 14 [104], in particular the 
minimum duration of 65ms shall be ensured. It is optional if the RTF Telephony Event is sent as a number of "RTF 
Events" with interim durations (e.g. every 20ms or 40ms in line with the speech packetisation time) or as a single "RTF 
Event" with the at least 65ms duration. 



MGCF - IM-MGW Interaction 



9.1 Overview 

The MGCF shall control the functions of the IM-MGW, which are used to provide the connection between media 
streams of an IF based transport network and bearer channels from a CS network. 

The MGCF shall interact with the IM-MGW across the Mn reference point. The MGCF shall terminate the signalling 
across the Mn interface towards the IM-MGW and the IM-MGW shall terminate the signalling from the MGCF. 

The signalling interface across the Mn reference point shall be defined in accordance with ITU-T Recommendation 
H.248.1 [2] and shall conform to 3GFF specific extensions as detailed in 3GFF TS 29.332 [15]. 

The present specification describes Mn signalling procedures and their interaction with BICC/ISUF and SIF signalling 
in the control plane, and with user plane procedures. 3GFF TS 29.332 [15] maps these signalling procedures to H.248 
messages and defines the required packages and parameters. 



9.2 IVIn signalling interactions 



The following paragraphs describe the Mn interface procedures triggered by SIF and BICC signalling relayed in 
MGCF. 

The SIF signalling occurring at the MGCF is described in 3GFF TS 24.229 [9]. 

All message sequence charts in this subclause are examples. 

9.2.1 Network model 

Figure 33 shows the network model, applicable to BICC and ISUF cases. The broken line represents the call control 
signalling. The dotted line represents the bearer control signalling (if applicable) and the user plane. The MGCF uses 
one context with two terminations in the IM-MGW. The termination Tl is used towards the IM CN subsystem entity 
and the bearer termination T2 is used for the bearer towards the succeeding CS network element. 
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Figure 33: Network model 

9.2.2 Basic IM CN subsystem originated session 
9.2.2.1 BICC forward bearer establishment 



9.2.2.1.1 



IM-MGW selection 



The MGCF shall select an IM-MGW for the bearer connection before it performs the CS network side bearer 
establishment. This may happen either before sending the lAM or after receiving the APM message (signal 5 or signal 6 
in figure 34). In the latter case, the IM-MGW selection may be based on a possibly received MGW-id from the 
succeeding node. 



9.2.2.1.2 



CS network side bearer establishment 



The MGCF shall either select bearer characteristics or request the IM-MGW to select and provide the bearer 
characteristics for the CS network side bearer connection before sending the lAM. In the latter case the MGCF shall use 
the Prepare Bearer procedure, not shown in figure 34, to request the IM-MGW to select the bearer characteristics. After 
the succeeding node has provided a bearer address and a binding reference in the APM, the MGCF shall use the 
Establish Bearer procedure to request the IM-MGW to establish a bearer towards the destination CS-MGW. The MGCF 
shall provide the IM-MGW with the bearer address, the binding reference and the bearer characteristics (signal 7 in 
figure 34). 



9.2.2.1.3 



IM CN subsystem side termination reservation 



On receipt of an initial INVITE (signal 1 in figure 34) the MGCF shall initiate the Reserve IMS Connection Point and 
Configure Remote Resources procedure (signal 3 and 4 in figure 34). From the received SDP and local configuration 
data the MGCF: 

Shall send the appropriate remote codec(s), the remote UDP port and the remote IP address to the IM-MGW. 
The remote UDP port and IP address refer to the destination of user plane data sent towards the IM CN 
subsystem. The remote codec(s) are the codec(s) the IM-MGW may select for user plane data sent towards the 
IM CN subsystem. 

Shall indicate to the IM-MGW the appropriate local codec(s) and request a local IP address and UDP port. The 
local IP address and UDP port are used by the IM-MGW to receive user plane data from the IM CN subsystem. 
The local codec(s) are the codec(s) the IM-MGW may select to receive user plane data from the IM CN 

subsystem. 

If DTMF support together with speech support is required, the reserve value indicator shall be set to "true". 

May indicate that IP interface type is for MboIP. 

The IM-MGW 

Shall reply to the MGCF with the selected local codec(s) and the selected remote codec(s) and the selected local 
UDP port and IP address. 
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Shall reserve resources for those codec(s). 

The MCGF shall send the local codec(s), UDP port and IP address to the IMS in the Session Progress (signal 9 in figure 
34). 

9.2.2.1 .4 IM CN subsystem side session establishment 

Dependent on what the MGCF receives in the PRACK message (signal 10 in figure 34), the MGCF may initiate the 
Configure IMS Resources procedure. If no SDP is received, or if the received SDP does not contain relevant changes 
compared to the previous SDP sent to the IMS in signal 9 in figure 34, the procedure is not invoked. Otherwise the 
MGCF shall use the Configure IMS Resources procedure to provide to the IM-MGW: 

The appropriate remote codec(s), the remote UDP port and the remote IP address. 

Optionally the appropriate local codec(s), UDP port and IP address. 

If DTMF support together with speech support is required, the reserve value indicator shall be set to "true". 

May indicate that IP interface type is for MboIP. 

The IM-MGW shall: 

Reply to the MGCF with the selected remote codec(s). 

Reply to the MGCF with the selected local codec(s)if the MGCF supplied local codec(s). 

Update the codec reservation and remote IP address and remote UDP port in accordance with the received 
information. 

The MGCF shall include the selected codec(s) and UDP port and IP address in a 200 OK (PRACK) (signal 1 1 in figure 
34) sent back to the IMS. 

9.2.2.1.5 Through-connection 

During the Prepare Bearer and Establish Bearer procedures, the MGCF shall either use the Change Through-Connection 
procedure to request the IM-MGW to backward through-connect the BICC terminations, or the MGCF shall use this 
procedure to both-way through-connect the BICC termination already on this stage (signal 7 in figure 34). During the 
Reserve IMS Connection Point procedure, the MGCF shall use the Change IMS Through-Connection procedure to 
request the IM-MGW to backward through-connect the IMS termination (signal 3 in figure 34). 

When the MGCF receives the BICC:ANM answer indication, it shall request the IM-MGW to both-way through- 
connect the termination using the Change Through-Connection or Change IMS Through-Connection procedures (signal 
22 in figure 34), unless those terminations are already both-way through-connected. 

9.2.2.1.6 Codec handling 

The IM-MGW may include a speech transcoder based upon the speech coding information provided to each 
termination. 

9.2.2.1 .7 Failure handling in MGCF 

If any procedure between the MGCF and the IM-MGW is not completed successfully the default action by the MGCF is 
to release the session, as described in subclause 9.2.6. If the MGCF receives a Bearer Released procedure from the IM- 
MGW the default action by the MGCF is to release the session as described in subclause 9.2.7. 

NOTE: As an implementation option the MGCF may also decide for example to only release the resources in the 
IM-MGW that caused the failure, possibly select a new IM-MGW for the connection and continue the 
call establishment using new resources in the selected IM-MGW but such handling is outside of the scope 
of the present document. 
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9.2.2.1 .8 Message sequence chart 

Figure 34 shows the message sequence chart for the IM CN subsystem originating session with BICC forward bearer 
establishment where the selection of IM-MGW is done before the sending of the lAM. In the chart the MGCF requests 
the seizure of an IM CN subsystem side termination. When the APM is received from the succeeding node, the MGCF 
requests the seizure of a CS network side bearer termination and the establishment of the bearer. When the MGCF 
receives an answer indication, it requests the IM-MGW to both-way through-connect the terminations. Dashed lines 
represent optional or conditional messages. 
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13. H.248 : MOD.resp [Context ID = CI , Termination ID = T1 ] 
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Figure 34: Basic IIVI CN Subsystem originating session, BICC forward bearer establishment 

(message sequence chart) 



£75/ 



3GPP TS 29.163 version 9.13.0 Release 9 170 ETSI TS 129 163 V9.13.0 (2013-04) 

9.2.2.2 BICC backward bearer establishment 

9.2.2.2.1 IM-MGW selection 

The MGCF shall select an IM-MGW for the bearer connection before it performs the IM CN subsystem session 
establishment or the CS network side bearer establishment, and before it sends the lAM (signal 8 in figure 35). 

9.2.2.2.2 IM CN subsystem side termination reservation 

On receipt of an initial INVITE (signal lin figure 35) the MGCF shall initiate the Reserve IMS Connection Point and 
Configure Remote Resources procedure (signal 3 and 4 in figure 35). From the received SDP and local configuration 
data the MGCF: 

Shall send the appropriate remote codec(s), the remote UDP port and the remote IP address to the IM-MGW. 
The remote UDP port and IP address refer to the destination of user plane data sent towards the IM CN 
subsystem. The remote codec(s) are the codec(s) the IM-MGW may select for user plane data sent towards the 
IM CN subsystem. 

Shall indicate to the IM-MGW the appropriate local codec(s) and request a local IP address and UDP port. The 
local UDP port and IP address are used by the IM-MGW to receive user plane data from the IM CN subsystem. 
The local codec(s) are the codec(s) the IM-MGW may select to receive user plane data from the IM CN 

subsystem. 

If DTMF support together with speech support is required, the reserve value indicator shall be set to "true". 

May indicate that IP interface type is for MboIP. 

The IM-MGW shall 

Reply to the MGCF with the selected local codec(s) and the selected remote codec(s) and the selected local UDP 
port and IP address. 

Reserve resources for those codec(s). 

The MCGF shall send the local codec(s), UDP port and IP address to the IMS in the Session Progress (signal 5 in figure 
35). 

9.2.2.2.3 IM CN subsystem side session establishment 

Dependent on what the MGCF receives in the PRACK message (signal 9 in figure 35) the MGCF may initiate the 
Select Configure IMS Resources procedure (signals 10 and 11 in figure 35). If no SDP is received, or if the received 
SDP does not contain relevant changes compared to the previous SDP the procedure is not invoked. Otherwise the 
MGCF shall use the Configure IMS Resources procedure to provide to the IM-MGW: 

the appropriate remote codec(s), the remote UDP port and the remote IP address. 

optionally if DTMF support together with speech support is required, the reserve value indicator shall be set to 

"true". 



May indicate that IP interface type is for MboIP. 

The IM-MGW shall: 

Reply to the MGCF with the selected remote codec(s). 

Reply to the MGCF with the selected local codec(s), if the MGCF supplied local codec(s). 

Update the codec reservation and remote IP address and remote UDP port in accordance with the received 
information. 

The MGCF shall include the selected codec(s), IP address and UDP port in an 200 OK (PRACK) (signal 12 in figure 
35) sent back to the IMS 
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9.2.2.2.4 CS network side bearer establishment 

The MGCF shall request the IM-MGW to prepare for the CS network side bearer establishment using the Prepare 
Bearer procedure before sending the lAM to the succeeding node. Within this procedure, the MGCF shall request the 
IM-MGW to provide a bearer address and a binding reference, and the MGCF shall either provide the IM-MGW with 
the preferred bearer characteristics or it shall request the IM-MGW to select and provide the bearer characteristics 
(signal 6 in figure 35). After the IM-MGW has replied with the bearer address, the binding reference and the bearer 
characteristics (if requested), the MGCF sends the lAM to the succeeding node (signal 8 in figure 35). 

9.2.2.2.5 Through-connection 

During the Prepare Bearer procedure, the MGCF shall either use the Change Through-Connection procedure to request 
the IM-MGW to backward through-connect the BICC termination, or the MGCF shall use this procedure to both-way 
through-connect the BICC termination already on this stage (signal 6 in figure 35). During the Reserve IMS Connection 
Point procedure, the MGCF shall use the Change IMS Through-Connection procedure to request the IM-MGW to 
backward through-connect the IMS termination (signal 3 in figure 35). 

When the MGCF receives the BICC:ANM answer indication, it shall request the IM-MGW to both-way through- 
connect the terminations using the Change Through-Connection or Change IMS Through-Connection procedures 
(signal 21 in figure 35), unless those terminations are already both-way through-connected. 

9.2.2.2.6 Codec handling 

The IM-MGW may include a speech transcoder based upon the speech coding information provided to each 
termination. 

9.2.2.2.7 Failure handling in MGCF 

If any procedure between the MGCF and the IM-MGW is not completed successfully the default action by the MGCF is 
to release the session as described in subclause 9.2.6. If the MGCF receives a Bearer Released procedure from the IM- 
MGW the default action by the MGCF is to release the session, as described in subclause 9.2.7. 

NOTE: As an implementation option the MGCF may also decide for example to only release the resources in the 
IM-MGW that caused the failure, possibly select a new IM-MGW for the connection and continue the 
call establishment using new resources in the selected IM-MGW but such handling is outside of the scope 
of the present document. 

9.2.2.2.8 Message sequence chart 

Figure 35 shows the message sequence chart for the IM CN subsystem originating session with BICC backward bearer 
establishment. In the chart the MGCF requests the seizure of an IM CN subsystem side termination and a CS network 
side bearer termination. When the MGCF receives an answer indication, it requests the IM-MGW to both-way through- 
connect the terminations. Dashed lines represent optional or conditional messages. 
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9.2.2.3 



ISUP 



9.2.2.3.1 



IM-MGW selection 



The MGCF shall select an IM-MGW with circuits to the given destination in the CS domain before it performs the IM 
CN subsystem session establishment and before it sends the lAM (signal 8 in figure 36). 
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9.2.2.3.2 IM CN subsystem side termination reservation 

On receipt of an initial INVITE (signal 1 in figure 36) the MGCF shall initiate the Reserve IMS Connection Point and 
Configure Remote Resources procedure (signal 3 and 4 in figure 36). From the received SDP and local configuration 
data the MGCF: 

shall send the appropriate remote codec(s), the remote UDP port and the remote IP address to the IM-MGW. The 
remote UDP port and IP address refer to the destination of user plane data sent towards the IM CN subsystem. 
The remote codec(s) are the codec(s) the IM-MGW may select for user plane data sent towards the IM CN 

subsystem. 

shall indicate to the IM-MGW the appropriate local codec(s) and request a local IP address and UDP port. The 
local IP address and UDP port are used by the IM-MGW to receive user plane data from the IM CN subsystem. 
The local codec(s) are the codec(s) the IM-MGW may select to receive user plane data from the IM CN 

subsystem. 

If DTMF support together with speech support is required, the reserve value indicator shall be set to "true". 

May indicate that IP interface type is for MboIP. 

The IM-MGW shall 

reply to the MGCF with the selected local codec(s) and the selected remote codec(s) and the selected local UDP 
port and IP address. 

reserve resources for those codec(s). 

The MCGF shall send selected local codec(s) and the selected remote codec and the selected local UDP port and IP 
address to the IMS in the Session Progress (signal 5 in figure 36) 

9.2.2.3.3 IM CN subsystem side session establishment 

Dependent on what the MGCF receives in the PRACK message (signal 9 in figure 35) the MGCF may initiate the 
Configure IMS Resources procedure. If no SDP is received, or if the received SDP does not contain relevant changes 
compared to the previous SDP, the procedure is not invoked. Otherwise the MGCF shall use the Configure IMS 
Resources procedure to provide to the IM-MGW: 

the appropriate remote codec(s), the remote UDP port and the remote IP address. 

optionally the appropriate local codec(s), UDP port and IP address. 

If DTMF support together with speech support is required, the reserve value indicator shall be set to "true". 

May indicate that IP interface type is for MboIP. 

The IM-MGW shall: 

reply to the MGCF with the selected remote codec. 

reply to the MGCF with the selected local codec(s), if the MGCF supplied local codec(s). 

update the codec reservation and remote IP address and UDP port in accordance with the received information. 

The MGCF shall include the selected codec(s) UDP port and IP address in 200 OK (PRACK) (signal 12 in figure 36) 
sent back to the IMS. 

9.2.2.3.4 CS network side circuit reservation 

The MGCF shall request the IM-MGW to reserve a circuit using the Reserve TDM Circuit procedure. The MGCF sends 
the lAM to the succeeding node including the reserved circuit identity. 

9.2.2.3.5 Through-connection 

During the Reserve TDM Circuit and Reserve IMS Connection Point procedures, the MGCF shall either use the Change 
TDM Through-Connection procedure to request the IM-MGW to backward through-connect the termination, or the 
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MGCF shall use this procedure to both-way through-connect the TDM termination already on this stage (signal 6 in 
figure 36). During the Reserve IMS connection Point procedure, the MGCF shall use the Change IMS through- 
connection procedure to request the IM-MGW to backward through-connect the IMS termination (signal 3 in figure 36). 

When the MGCF receives the ISUP:ANM answer indication, it shall request the IM-MGW to both-way through- 
connect the terminations using the Change IMS Through-Connection or Change TDM Through-Connection procedures 
(signal 21 in figure 36), unless those terminations are already both-way through-connected. 

9.2.2.3.6 Continuity check 

The MGCF may request a continuity check on the connection towards the CS network within the lAM message. In this 
case, the MGCF shall use the Continuity Check procedure towards the IM-MGW to request the generation of a 
continuity check tone on the TDM termination. The IM-MGW shall then use the Continuity Check Verify procedure to 
notify the MGCF of an incoming continuity check tone on the corresponding circuit. In addition to other conditions 
detailed in Section 7, the MGCF shall wait until receiving this notification before sending the COT. (Not depicted in 
figure 36) 

9.2.2.3.7 Codec handling 

The IM-MGW may include a speech transcoder based upon the speech coding information provided to each 
termination. 

9.2.2.3.8 Voice processing function 

A voice processing function located on the IM-MGW may be used to achieve desired acoustic quality on the 
terminations. If the voice processing function is used, the MGCF shall request the activation of it in the termination 
towards the CS network using the Activate TDM Voice Processing Function procedure (signal 23 in figure 36). 

9.2.2.3.9 Failure handling in MGCF 

If any procedure between the MGCF and the IM-MGW is not completed successfully session shall be released as 
described in subclause 9.2.6. If the MGCF receives a Bearer Released procedure from the IM-MGW the default action 
by the MGCF is to release the session as described in subclause 9.2.7. 

9.2.2.3.10 Message sequence chart 

Figure 36 shows the message sequence chart for the IM CN subsystem originating session. In the chart the MGCF 
requests the seizure of an IM CN subsystem side termination and a CS network side bearer termination. When the 
MGCF receives an answer indication, it requests the IM-MGW to both-way through-connect the terminations. The 
MGCF requests the possible activation of the voice processing functions for the bearer terminations. Dashed lines 
represent optional or conditional messages. 
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Figure 36: Basic IIVI CN Subsystem originating session, ISUP (message sequence chart) 
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9.2.3 Basic CS network originated session 
9.2.3.1 BICC forward bearer establishment 

9.2.3.1.1 IM-MGW selection 

The MGCF shall select an IM-MGW for the bearer connection before it performs the IM CN subsystem session 
establishment or the CS network side bearer establishment. 

9.2.3.1 .2 IM CN subsystem side termination reservation 

The MGCF shall derive from configuration data one or several appropriate local codec(s) the IM-MGW may use to 
receive user plane data from the IM CN subsystem. The MGCF shall use the Reserve IMS Connection Point procedure 
(signals 2 and 3 in figure 37). Within this procedure, the MGCF shall indicate the local codec(s) and request a local IP 
address and UDP port from the IM-MGW. The local IP address and UDP port are used by the IM-MGW to receive user 
plane data from the IM CN subsystem. If DTMF support together with speech support is required, or if the resources for 
multiple speech codecs shall be reserved at this stage, the reserve value indicator shall be set to "true". 

The MGCF may also indicate that the IP interface type is for MboIP. 

The IM-MGW shall reply to the MGCF with the selected local codec(s) and the selected local IP address and UDP port. 

The MGCF shall send this information in the INVITE (signal 4 in figure 37) to the IM CN subsystem. 

9.2.3.1 .3 IM CN subsystem side session establishment 

The MGCF shall use the Configure IMS Resources procedure (signals 7 and 8 or 23a and 23b in figure 37) to provide 
configuration data (derived from SDP received in signal 6 in figure 37 and local configuration data) to the IM-MGW as 
detailed below: 

The MGCF shall indicate the remote IP address and UDP port, i.e. the destination IP address and UDP port for 
data sent in the user plane towards the IM CN subsystem. 

The MGCF shall indicate the remote codec(s), i.e. the speech codec(s) for data sent in the user plane towards the 
IM CN subsystem. 

The MGCF may indicate the local codec(s) and the local IP address and UDP port. The MGCF shall indicate the 
local codec(s) if a change is required. 

IF DTMF support together with speech support is required, the reserve value indicator shall be set to "true". 

The MGCF may indicate that IP interface type is for MboIP. 

The IM-MGW shall reply with the selected remote codec(s) and reserve resources for these codec(s). If local codec(s) 
were received, the IM-MGW shall also reply with the selected local codec(s) and reserve the corresponding resources. 

If the selected local codec(s) differ from the codec(s) received in the SDP of signal 6 in figure 37 (if any), the MGCF 
shall send the local reserved codec(s), and the local IP address and UDP port in the PRACK (signal 9 in figure 37) to 
the IMS. 

If the selected local codec(s) differ from the codec(s) received in the SDP of signal 23 in figure 37 (if any), the MGCF 
shall send the local reserved codec(s), and the local IP address and UDP port in an re-INVITE or UPDATE (not 
depicted in figure 37) to the IMS. 

9.2.3.1 .4 CS network side bearer establishment 

The MGCF shall request the IM-MGW to prepare for the CS network side bearer establishment using the Prepare 
Bearer procedure (signals 1 1 and 12 in figure 37). Within this procedure, the MGCF shall request the IM-MGW to 
provide a bearer address, a binding reference and optionally notify when the bearer is established. The MGCF shall also 
provide the IM-MGW with the bearer characteristics that was received from the preceding node in the lAM. After the 
IM-MGW has replied with the bearer address and the binding reference, the MGCF provides the APM message (signals 
13 in figure 37) to the preceding node. The MGCF may also provide the IM-MGW-id in the APM message. 
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9.2.3.1 .5 Called party alerting 

The MGCF shall request the IM-MGW to provide an awaiting answer indication (ringing tone) to the calling party 
using the Send Tone procedure (signals 20 and 21 in figure 37) , when the following condition is satisfied: 

the MGCF receives the first 180 Ringing message, unless this message or some previous SIP provisional 
response contained a P-Early-Media header field that authorizes early media. 

9.2.3.1 .6 Called party answer 

When the MGCF receives a 200 OK message (signal 23 in figure 34), it shall request the IM-MGW to stop providing 
the ringing tone to the calling party using the Stop Tone procedure (signals 26 and 27 in figure 37). 

9.2.3.1.7 Through-Connection 

During the Prepare Bearer procedure, the MGCF shall either use the Change Through-Connection procedure to request 
the IM-MGW to backward through-connect the BICC termination, or the MGCF shall use this procedure to both-way 
through-connect the BICC termination already on this stage (signals 1 1 and 12 in figure 37). During the Reserve IMS 
Connection Point procedure, the MGCF shall use the Change IMS Through-Connection procedure to request the IM- 
MGW to backward through-connect the IMS termination (signals 2 and 3 in figure 37). 

When the MGCF receives the SIP 200 OK(INVITE) (signal 23 in figure 37), it requests the IM-MGW to both-way 
through-connect the terminations using the Change IMS Through-Connection or Change Through-Connection 
procedures (signals 28 and 29 in figure 37), unless those terminations are already both-way through-connected. 

9.2.3.1.8 Codec handling 

The IM-MGW may include a speech transcoder based upon the speech coding information provided to each 
termination. 

9.2.3.1 .9 Failure handling in MGCF 

If any procedure between the MGCF and the IM-MGW is not completed successfully, the default action by the MGCF 
is to release the session as described in subclause 9.2.6. If the MGCF receives a Bearer Released procedure from the 
IM-MGW the default action by the MGCF is to release the session, as described in subclause 9.2.7. 

NOTE: As an implementation option the MGCF may also decide for example to only release the resources in the 
IM-MGW that caused the failure, possibly select a new IM-MGW for the connection and continue the 
call establishment using new resources in the selected IM-MGW but such handling is outside of the scope 
of the present document. 

9.2.3.1.10 Message sequence chart 

Figure 37 shows the message sequence chart for the CS network originating session with BICC forward bearer 
establishment. In the chart the MGCF requests the seizure of the IM CN subsystem side termination and CS network 
side bearer termination. When the MGCF receives an answer indication, it requests the IM-MGW to both-way through- 
connect the terminations. Dashed lines represent optional or conditional messages. 
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9.2.3.2 



BICC Backward bearer establishment 



9.2.3.2.1 



IM-MGW selection 



The MGCF shall select an IM-MGW for the bearer connection before it performs the IM CN subsystem session 
establishment or the CS network side bearer establishment. 



9.2.3.2.2 



CS network side bearer establishment 



The MGCF shall request the IM-MGW to establish a bearer using the Establish Bearer procedure (signals 2 and 3 in 
figure 38). The MGCF provides the IM-MGW with the bearer address, the binding reference and the bearer 
characteristics that were received from the preceding node in the lAM (signal 1 in figure 38). 



9.2.3.2.3 



IM CN subsystem side termination reservation 



The MGCF shall derive from configuration data one or several appropriate local codec(s) the IM-MGW may use to 
receive user plane data from the IM CN subsystem. The MGCF shall use the Reserve IMS Connection Point procedure 
(signals 2 and 3 in figure 38). Within this procedure, the MGCF shall indicate the local codec(s) and request a local IP 
address and UDP port from the IM-MGW. The local IP address and UDP port are used by the IM-MGW to receive user 
plane data from the IM CN subsystem. If DTMF support together with speech support is required, or if the resources for 
multiple speech codecs shall be reserved at this stage, the reserve value indicator shall be set to "true". 

The MGCF may also indicate that the IP interface type is for MboIP. 

The IM-MGW shall reply to the MGCF with the selected local codec(s) and the selected local IP address and UDP port. 

The MGCF shall send this information in the INVITE (signal 6 in figure 38) to the IM CN subsystem. 
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9.2.3.2.4 IM CN subsystem side session establishment 

The MGCF shall use the Configure IMS Resources procedure (signals 9 and 10 or 22a and 22b in figure 38) to provide 
configuration data (derived from SDP received in signal 8 in figure 38 and local configuration data) to the IM-MGW as 
detailed below: 

The MGCF shall indicate the remote IP address and UDP port, i.e. the destination IP address and UDP port for 
data sent in the user plane towards the IM CN subsystem 

The MGCF shall indicate the remote codec(s), i.e. the speech codec(s) for data sent in the user plane towards the 
IM CN subsystem. 

The MGCF may indicate the local codec(s) and the local IP address and UDP port. The MGCF shall indicate the 
local codec(s) if a change is required. 

If DTMF support together with speech support is required, the reserve value indicator shall be set to "true". 

The MGCF may indicate that IP interface type is for MboIP. 

The IM-MGW shall reply with the selected remote codec(s) and reserve resources for this codec. If local codec(s) were 
received, the IM-MGW shall also reply with the selected local codec(s) and reserve the corresponding resources. 

If the selected local codec(s) differ from the codec(s) received in the SDP of signal 8 in figure 38 (if any), the MGCF 
shall send the reserved speech codec(s), and the local IP address and UDP port in the PRACK (signal 11 in figure 38) to 
the IMS. 

If the selected local codec(s) differ from the codec(s) received in the SDP of signal 22 in figure 38 (if any), the MGCF 
shall send the local reserved codec(s), and the local IP address and UDP port in an re-INVITE or UPDATE (not 
depicted in figure 38) to the IMS. 

9.2.3.2.5 Called party alerting 

The MGCF shall request the IM-MGW to provide an awaiting answer indication (ringing tone) to the calling party 
using the Send Tone procedure (signals 19 and 20 in figure 38) , when the following conditions is satisfied: 

the MGCF receives the first 180 Ringing message, unless this message or some previous SIP provisional 
response contained a P-Early-Media header t field hat authorizes early media and the MGCF supports the P- 
Early-Media header as a network option. 

9.2.3.2.6 Called party answer 

When the MGCF receives a 200 OK message (signal 22 in figure 38), it shall request the IM-MGW to stop providing 
the ringing tone to the calling party using the Stop Tone procedure (signals 23 and 24 in figure 38). 

9.2.3.2.7 Through-Connection 

During the Establish Bearer procedure, the MGCF shall either use the Change Through-Connection procedure to 
request the IM-MGW to backward through-connect the BICC termination, or the MGCF shall use this procedure to 
both-way through-connect the BICC termination already on this stage (signals 2 and 3 in figure 38). During the Reserve 
IMS Connection Point procedure, the MGCF shall use the Change IMS Through-Connection procedure to request the 
IM-MGW to backward through-connect the IMS termination (signals 4 and 5 in figure 38). 

When the MGCF receives the SIP 200 OK(INVITE) (signal 22 in figure 38), it shall request the IM-MGW to both-way 
through-connect the bearer using the Change IMS Through-Connection or Change Through-Connection procedure 
(signals 25 and 26 in figure 38), unless those terminations are already both-way through-connected. 

9.2.3.2.8 Codec handling 

The IM-MGW may include a speech transcoder based upon the speech coding information provided to each 
termination. 
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9.2.3.2.9 Failure handling in MGCF 

If any procedure between the MGCF and the IM-MGW is not completed successfully, the default action by the MGCF 
is to release the session as described in subclause 9.2.6. If the MGCF receives a Bearer Released procedure from the 
IM-MGW the default action by the MGCF is to release the session as described in subclause 9.2.7. 

NOTE: As an implementation option the MGCF may also decide for example to only release the resources in the 
IM-MGW that caused the failure, possibly select a new IM-MGW for the connection and continue the 
call establishment using new resources in the selected IM-MGW but such handling is outside of the scope 
of the present document. 

9.2.3.2.10 Message sequence chart 

Figure 38 shows the message sequence chart for the CS network originating session with BICC backward bearer 
establishment. In the chart the MGCF requests seizure of the IM CN subsystem side termination and CS network side 
bearer termination. When the MGCF receives an answer indication, it requests the IM-MGW to both-way through- 
connect the terminations. Dashed lines represent optional or conditional messages. 
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Figure 38/1 : Basic CS Networit Originating Session, BICC Backward Bearer Establishment (message 

sequence chart) 
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Figure 38/2: Basic CS Networit Originating Session, BICC Backward Bearer Establishment 

(message sequence chart continue) 



9.2.3.3 



ISUP 



9.2.3.3.1 IM-MGW selection 

The MGCF selects the IM-MGW based on the received circuit identity in the lAM. 

9.2.3.3.2 CS network side circuit reservation 

The MGCF shall request the IM-MGW to reserve a circuit using the Reserve TDM Circuit procedure. 



9.2.3.3.3 



IM CN subsystem side termination reservation 



The MGCF shall derive from configuration data one or several appropriate local codec(s) the IM-MGW may use to 
receive user plane data from the IM CN subsystem. The MGCF shall use the Reserve IMS Connection Point procedure 
(signals 2 and 3 in figure 39). Within this procedure, the MGCF shall indicate the local codec(s) and request a local IP 
address and UDP port from the IM-MGW. The local IP address and UDP port are used by the IM-MGW to receive user 
plane data from the IM CN subsystem. If DTMF support together with speech support is required, or if the resources for 
multiple speech codecs shall be reserved at this stage, the reserve value indicator shall be set to "true". 

The MGCF may also indicate that the IP interface type is for MboIP. 

The IM-MGW shall reply to the MGCF with the selected local codec(s) and the selected local IP address and UDP port. 

The MGCF shall send this information in the INVITE (signal 6 in figure 39) to the IM CN subsystem. 



9.2.3.3.4 



IM CN subsystem side session establishment 



The MGCF shall use the Configure IMS Resources procedure (signals 9 and 10 or 22a and 22b in figure 39) to provide 
configuration data (derived from SDP received in signal 8 in figure 39 and local configuration data) as detailed below: 
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The MGCF shall indicate the remote IP address and UDP port, i.e. the destination IP address and UDP port for 
data sent in the user plane towards the IM CN subsystem. 

The MGCF shall indicate the remote codec(s), i.e. the speech codec(s) for data sent in the user plane towards the 
IM CN subsystem. 

The MGCF may indicate the local codec(s) and the local IP address and UDP port. The MGCF shall indicate the 
local codec(s) if a change is required. 

If DTMF support together with speech support is required, the reserve value indicator shall be set to "true". 

The MGCF may indicate that IP interface type is for MboIP. 

The IM-MGW shall reply with the selected remote codec(s) and reserve resources for these codec(s). If local codec(s) 
were received, the IM-MGW shall also reply with the selected local codec(s) and reserve the corresponding resources. 

If the selected local codec(s) differ from the codec(s) received in the SDP of signal 8 in figure 39 (if any), the MGCF 
shall send the reserved speech codec(s), and the local IP address and UDP port in the PRACK (signal 1 1 in figure 39) to 
the IMS. 

If the selected local codec(s) differ from the codec(s) received in the SDP of signal 22 in figure 39 (if any), the MGCF 
shall send the local reserved codec(s), and the local IP address and UDP port in an re-INVITE or UPDATE (not 
depicted in figure 39) to the IMS. 

9.2.3.3.5 Called party alerting 

The MGCF shall request the IM-MGW to provide an awaiting answer indication (ringing tone) to the calling party 
using the Send TDM Tone procedure (signals 19 and 20in figure 39), when the following condition is satisfied: 

the MGCF receives the first 180 Ringing message, unless this message or some previous SIP provisional 
response contained a P-Early-Media header that authorizes early media. 

9.2.3.3.6 Called party answer 

When the MGCF receives a 200 OK message (signal 22 in figure 39), it shall request the IM-MGW to stop providing 
the ringing tone to the calling party using the Stop TDM Tone procedure (signals 23 and 24 in figure 39). 

9.2.3.3.7 Through-Connection 

Within the Reserve TDM Circuit procedure, the MGCF shall either use the Change TDM Through-Connection 
procedure to request the IM-MGW to backward through-connect the TDM termination, or the MGCF shall use this 
procedure to both-way through-connect the TDM termination already on this stage (signals 2 and 3 in figure 39). 
During the Reserve IMS Connection Point procedure, the MGCF shall use the Change IMS Through-Connection 
procedure to request the IM-MGW to backward through-connect the IMS termination (signals 4 and 5 in figure 39). 

When the MGCF receives the SIP 200 OK(INVITE) message, it shall request the IM-MGW to both-way through- 
connect the terminations using the Change IMS Through-Connection or Change TDM Through-Connection procedure 
(signals 25 and 26 in figure 39), unless those terminations are already both-way through-connected. 

9.2.3.3.8 Continuity Check 

If a continuity check on the connection towards the CS network is requested in the lAM message, the MGCF shall use 
the Continuity Check Response procedure towards the IM-MGW to request loop-back of a received continuity check 
tone on the TDM circuit. Upon reception of the COT message, the MGCF shall use the Continuity Check Response 
procedure towards the IM-MGW to request the removal of the loop-back. (Not depicted in figure 39) 

9.2.3.3.9 Codec handling 

The IM-MGW may include a speech transcoder based upon the speech coding information provided to each 
termination. 
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9.2.3.3.10 Voice Processing function 

A voice processing function located on the IM-MGW may be used to achieve desired acoustic quality on the 
terminations. If the voice processing function is used, the MGCF shall request the activation of it in the termination 
towards the CS network using the Activate TDM Voice Processing Function procedure (signal 23 in figure 39). 

9.2.3.3.1 1 Failure handling in MGCF 

If any procedure between the MGCF and the IM-MGW is not completed successfully, the session shall be released as 
described in subclause 9.2.6. If the MGCF receives a Bearer Released procedure from the IM-MGW the default action 
by the MGCF is to release the session as described in subclause 9.2.7. 

9.2.3.3.12 Message sequence chart 

Figure 39 shows the message sequence chart for the CS network originating Session with ISUP. In the chart the MGCF 
requests seizure of the IM CN subsystem side termination and CS network side bearer termination. When the MGCF 
receives an answer indication, it requests the IM-MGW to both-way through-connect the terminations. The MGCF may 
request the possible activation of the voice processing functions for the terminations. Dashed lines represent optional or 
conditional messages. 
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Figure 39/1 : Basic CS Networit Originating Session, ISUP (message sequence chart) 
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Figure 39/2: Basic CS Networic Originating Session, ISUP (message sequence chart continue) 



9.2.3.4 Handling of Forking 

The procedures described in subclauses 9.2.3.1 to 9.2.3.3 shall be applied with the following additions. 



9.2.3.4.1 



Detection of Forking 



According to SIP procedures, the O-MGCF inspects the tags in the "to" SIP header fields of provisional and final 
responses to identify the SIP dialogue the response belongs to. If responses belonging to different dialogues are 
received (signals 8 and 13 in figure 39a), the INVITE request (signal 6 in figure 39a) has been forked. 



9.2.3.4.2 



IM CN subsystem side session establishment 



If SDP is received in a provisional response and more than one SIP dialogue exists (signal 13 in figure 39a), the MGCF 
may either refrain from reconfiguring the IM-MGW, or it may use the Configure IMS Resources procedure (signals 14 
and 15 in figure 39a) as detailed below: 

If the MGCF receives a SIP provisional response containing a P-Early-Media header field that authorizes early 
media, the MGCF shall provide the remote IP address and UDP port, and the remote codec selected from the 
received SDP and local configuration data, corresponding to the SIP dialogue of the SIP provisional response 
containing a P-Early-Media header field that authorizes early media. The IM-MGW may be configured to use 
the remote IP address and port information as source filter for incoming packages to prevent that early media 
from other early SIP dialogues interfere. The MGCF may also provide an IP address and port source filter that 
disallows early media from other early dialogues without an early media authorization in order to prevent that 
such unauthorized early media interfere with the authorized early media. (NOTE 1, NOTE 2) 

If the MGCF did not receive any SIP provisional response containing a P-Early-Media header field that 
authorizes early media, the MGCF may compare the selected local codecs of the different dialogues (which the 
MGCF selects due to the received SDP answer and local configuration data). If different local codecs are 
selected for the different dialogues, the MGCF may include all these codecs in the "local IMS resources", and set 
the "reserve value" to indicate that resources for all these codecs shall be reserved. Alternatively, the MGCF may 
only include the codecs received in the last SDP in the "local IMS resources". 

If the MGCF did not receive any SIP provisional response containing a P-Early-Media header field that 
authorizes early media, the MGCF may update the "remote IMS resources" with the information received in the 
latest SDP. The MGCF should provide the remote IP address and UDP port, and the remote codec selected from 
the received SDP and local configuration data. (NOTE 3) 
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NOTE 1: The O-MGCF can use the P-Early-Media header field (IETF RFC 5009 [89]) to determine whether the 
media associated with a forked dialog is authorized and thus eligible for a through connection. In the 
presence of early media for multiple dialogs due to forking, if the IM-MGW is able to identify the media 
associated with a dialog (i.e., if symmetric RTP is used by the peer and the IM-MGW can use the remote 
SDP information to determine the source of the media), then the O-MGCF/IM-MGW can selectively 
establish a through-connection for an authorized early media flow. 

NOTE 2: The behaviour of an O-MGCF upon the possible reception of SIP provisional responses containing P- 
Early-Media header fields that authorize early media for several early dialogues is left unspecified. 

NOTE 3: The behaviour in the third bullet is beneficial if forking is applied in a sequential manner. 

9.2.3.4.3 IM CN subsystem side session establishment completion 

Upon reception of the first final 2xx response (signal 32 in figure 39a), the MGCF shall use the Configure IMS 
Resources procedure (signals 35 and 36 in figure 39a) as detailed below unless the IM-MGW is already configured 
accordingly: 

If the remote IMS resources configured at the IM-MGW do not match the remote resources selected for the 
established dialogue of the final response, the MGCF shall provide the remote IP address and UDP port from the 
latest received SDP of this established dialogue, and the remote codec selected from the latest received SDP of 
this established dialogue and local configuration data within the "remote IMS resources". 

If the local IMS resources configured at the IM-MGW contain more codecs than selected for the established 
dialogue of the final response, the MGCF should update the "local IMS resources" with the selected local codec 
derived from the latest SDP of this established dialogue and local configuration data. The "reserve value" may be 
cleared unless it is required for DTMF. 

The IM-MGW may be configured to use the remote IP address and port information as source filter for incoming 
packages to prevent that early media from other early SIP dialogues interfere with the media of the established 
dialogue. The MGCF may also provide an IP address and port source filter that disallows early media from other 
early dialogues in order to prevent that such early media interfere with the media of the established dialogue. If 
the MGCF has provided a source filter selecting media of another SIP early dialogue, it shall remove or update 
this source filter. 

9.2.3.4.4 Message sequence chart 

Figure 39a shows an example message sequence chart for a CS network originating Session Setup with ISUP, where 
forking occurs. 
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Figure 39a/1 : CS Network Originating Session with forlting, ISUP (message sequence chart) 
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Figure 39a/2: CS Network Originating Session with forlting, ISUP (message sequence chart continue) 
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9.2.4 Session release initiated from IM CN subsystem side 

9.2.4.1 BICC 



9.2.4.1.1 



Session release in the IM CN subsystem side 



When the MGCF has received a BYE message from the IM CN subsystem side, the MGCF shall release resources in 
the IM-MGW serving the relevant Mb interface connection by using the "Release IMS Termination" procedure (signals 
5 and 6 in figure 40). After receiving the BYE message, the MGCF shall also send a 200 OK [BYE] message towards 
the IM CN subsystem (signal 2 in figure 40). 



9.2.4.1.2 



Session release in the CS network side 



When the MGCF has received a BYE message from the IM CN subsystem side, the MGCF shall send a REL message 
to the succeeding node (signal 3 in figure 40). Once the succeeding node has responded with the RLC message (signal 6 
in figure 40), the MGCF shall release the resources for the CS network side in the IM-MGW. If any resources were 
seized in the IM-MGW, the MGCF shall use the "Release Bearer", "Change Through-Connection" and "Release 
Termination" procedures (signals 7 to 10 in figure 40) to indicate to the IM-MGW that the CS network side bearer 
termination shall be removed and the bearer shall be released towards the succeeding MGW. 

9.2.4.1 .3 Message sequence chart 

Figure 40 shows the message sequence chart for the session release initiated from the IM CN subsystem side. 
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7. H.248 : MOD.req [Context ID = CI, Termination ID = T2] 



8. H.248 : IVIOD.resp [Context ID = C1, Termination ID = T2] 



9. H.248 : SUB.req [Context ID = C1 .Termination ID = T2] 



10. tL248: SUB.resp [Context ID = CI, Termination ID = T2] 



Figure 40: Session release from IIU! CN subsystem side for BICC (message sequence chart) 
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9.2.4.2 



ISUP 



9.2.4.2.1 



Session release in the IM CN subsystem side 



When the MGCF has received a BYE message from the IM CN subsystem side, the MGCF shall release resources in 
the IM-MGW serving the relevant Mb interface connection by using the "Release IMS Termination" procedure (signals 
4 and 5 in figure 41). After receiving the BYE message, the MGCF shall also send a 200 OK [BYE] message towards 
the IM CN subsystem (signal 2 in figure 41). 



9.2.4.2.2 



Session release in the CS network side 



When the MGCF has received a BYE message from the IM CN subsystem side, the MGCF shall send a REL message 
to the succeeding node (signal 3 in figure 41). After sending the REL message, the MGCF shall expect a RLC message 
(signal 8 in figure 41) from the succeeding node. The MGCF shall also release the resources for the CS network side in 
the IM-MGW. If any resources were seized in the IM-MGW, the MGCF shall use the "Release TDM Termination" 
procedure (signals 6 to 7 in figure 41) to indicate to the IM-MGW that the CS network side bearer termination can be 
released. 

9.2.4.2.3 Message sequence chart 

Figure 41 shows the message sequence chart for the session release initiated from the IM CN subsystem side. 



MGCF 



1. SIP: BYE 



2. S!P: 200 OK [BYE] 



Release IMS Termination 



Release TDM Termination 



3. ISUP: REL 



4. H.248 : SUB.req [Context ID = C1, Termination ID = T1] 



5. H.248 : SUB.resp [Context ID = C1 , Termination ID = T1] 



6. H.248 : SUB.req [Context ID = C1 , Termination ID = T2] 



7. H.248 : SUB.resp [Context ID = C1 , Termination ID = T2] 



8. ISUP: RLC 



Figure 41 : Session release from IM CN subsystem side for ISUP (message sequence chart) 

9.2.5 Session release initiated from CS network side 



9.2.5.1 



BICC 



9.2.5.1.1 



Session release in the CS network side 



When the MGCF receives a REL message from the preceding node (signal 1 in figure 42), the MGCF shall release 
resources for the CS network side in the IM-MGW. If any resources were seized in the IM-MGW, the MGCF shall use 
the "Release Bearer", "Change Through-Connection" and "Release Termination" procedures to indicate to the IM- 
MGW that the CS network side bearer termination shall be removed and the bearer shall be released towards the 
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preceding MGW (signal 3 to 6 in figure 42). After completion of resource release, the MGCF shall send a RLC message 
towards the preceding node. 



9.2.5.1.2 



Session release in the IM CN subsystem side 



When the MGCF receives a REL message from the preceding node (signal 1 in figure 42), the MGCF shall send a BYE 
message to the IM CN subsystem (signal 2 in figure 42) and the MGCF shall release the resources in the IM-MGW 
serving the relevant Mb interface connection by using the "Release IMS Termination" procedure (signals 7 and 8 in 
figure 42). The MGCF shall also expect to receive a 200 OK [BYE] message from the IM CN subsystem side (signal 10 
in figure 42). 

9.2.5.1 .3 Message sequence chart 

Figure 42 shows the message sequence chart for the session release initiated from the CS network side. 



Release Bearer, 
Change Through- 
Connection = backward 



Release Termination 



Release IMS 
Termination 



1 .BICC: REL 



3. H.248 : MOD.req [Context ID = C1 , Termination ID = T2] 



4. H.248 : MOD.resp [Context ID =C1 , Termination ID =T2] 



5. H.248 : SUB.req [Context ID = C1 .Termination ID = T2] 



6. H.248 : SUB.resp [Context ID =C1 , Termination ID =T2 ] 



7. H.248 : SUB.req [Context ID = C1 , Termination ID = T1] 



8. H.248 : SUB.resp [Context ID = C1, Termination ID = T1] 



9. BICC : RLC 



2. SIP: BYE 



10. S!P: 200 OK [BYE] 



Figure 42: Session release from CS networit side for BICC (message sequence chart) 



9.2.5.2 



ISUP 



9.2.5.2.1 



Session release in the CS network side 



When the MGCF receives a REL message from the preceding node (signal 1 in figure 43), the MGCF shall release 
resources for the CS network side in the IM-MGW. If any resources were seized in the IM-MGW, the MGCF shall use 
the "Release TDM Termination procedures" to indicate to the IM-MGW that the CS network side bearer termination 
can be released (signal 3 to 4 in figure 43). After completion of resource release, the MGCF shall send a RLC message 
towards the preceding node. 



9.2.5.2.2 



Session release in the IM CN subsystem side 



When the MGCF receives a REL message from the preceding node (signal 1 in figure 43), the MGCF shall send a BYE 
message to the IM CN subsystem (signal 2 in figure 43) and the MGCF shall release the resources in the IM-MGW 
serving the relevant Mb interface connection by using the "Release IMS Termination" procedure (signal 5 to 6 in figure 
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43). The MGCF shall also expect to receive a 200 OK [BYE] message from the IM CN subsystem side (signal 8 in 
figure 43). 

9.2.5.2.3 Message sequence chart 

Figure 43 shows the message sequence chart for the session release initiated from the CS network side. 





IM-MGW 




MGCF 










1.ISUP: REL 












3. H.248: SUB.req [Context ID = C1 .Termination ID = T2] 


2. SIP: BYE 






Release TDM 
Termination 


4. H.248: SUB.resp [Context ID = C1 . Termination ID = T21 






5. H.248: SUB.req [Context ID = C1 . Termination ID = Tl] 




Release IMS 
Termination 


6. H.248: SUB.resp [Context ID =C1, Termination ID =T1] 






7. ISUP: RLC 










^ 8. SIP: 200 OK IBYEI 









Figure 43: Session release from CS network side for ISUP (message sequence chart) 

9.2.6 Session release initiatecJ by MGCF 

9.2.6.1 BICC 



9.2.6.1.1 



Session release in the CS network side 



The MGCF shall send a REL message to the succeeding node on the CS network side (signal 1 in figure 44) Once the 
succeeding node has responded with the RLC message (signal 3 in figure 44), the MGCF shall release the resources for 
the CS network side in the IM-MGW. If any resources were seized in the IM-MGW, the MGCF shall use the "Release 
Bearer", "Change Through-Connection" and "Release Termination" procedures to indicate to the IM-MGW that the CS 
network side bearer termination shall be removed and the bearer shall be released towards the succeeding MGW (signal 
4 to 7 in figure 44). 



9.2.6.1.2 



Session release in the IM CN subsystem side 



The MGCF shall sends a BYE message to the IM CN subsystem side (signal 2 in figure 44) and the MGCF shall release 
the resources in the IM-MGW serving the relevant Mb interface connection by using the "Release IMS Termination" 
procedure (signals 8 and 9 in figure 44). The MGCF shall also expect to receive a 200 OK [BYE] message is received 
from the IM CN subsystem side (signal 10 in figure 44). 

9.2.6.1 .3 Message sequence chart 

Figure 44 shows the message sequence chart for the session release initiated by the MGCF. 
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2. S!P: BYE 



Release Bearer, 
Change Through- 
Connection = backward 



Release Termination 



Release IMS 
Termination 



10. S!E: 200 OK [BYE] 



1. BICC: REL 



3. BICC: RLC 



4. H.248 : MOD.req [Context ID = CI, Termination ID = T2] 



5. H.248 : MOD.resp [Context ID = CI, Termination ID = T2] 



6. H.248 : SUB.req [Context ID = C1 .Termination ID = T2] 



7. H.248 : SUB.resp [Context ID = C1 , Termination ID = T2 ] 



8. H.248 : SUB.req [Context ID = C1 , Termination ID = T1] 



9. H.248 : SUB.resp [Context ID = C1, Termination ID = T1] 



Figure 44: Session release initiated by IVIGCF for BICC (message sequence chart) 



9.2.6.2 



ISUP 



9.2.6.2.1 



Session release in the CS network side 



The MGCF shall send a REL message to the succeeding node on the CS network side (signal 2 in figure 45) and the 
MGCF shall release the resources for the CS network side in the IM-MGW. If any resources were seized in the IM- 
MGW, the MGCF shall use the "Release TDM Termination" procedure to indicate to the IM-MGW that the CS network 
side termination shall be released (signal 5 to 6 in figure 45). The MGCF shall also expect to receive a RLC message 
from the succeeding node on the CS network side (signal 7 in figure 45). 



9.2.6.2.2 



Session release in the IM CN subsystem side 



The MGCF shall send a BYE message to the IM CN subsystem side (signal 1 in figure 45) and the MGCF shall release 
the resources in the IM-MGW serving the relevant Mb interface connection by using the "Release IMS Termination" 
procedure (signal 5 to 6 in figure 45). The MGCF shall also expect to receive a 200 OK [BYE] message from the IM 
CN subsystem side (signal 8 in figure 45). 

9.2.6.2.3 Message sequence chart 

Figure 45 shows the message sequence chart for the session release initiated by the MGCF. 
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MGCF 



1. SIP: BYE 



Release IMS 
Termination 



Release TDM 
Termination 



8. S!P: 200 OK [BYE] 



IM-MGW 



2. ISUP: REL 



3. H.248 : SUB.req [Context ID = C1, Termination ID = T1] 



4. H.248 : SUB.resp [Context ID = C1 , Termination ID = T1] 



5. H.248 : SUB.req [Context ID = C1 .Termination ID = T2] 



6. H.248 : SUB.resp [Context ID = C1 , Termination ID = T2 ] 



7. ISUP: RLC 



Figure 45: Session release initiated by IVIGCF for ISUP (message sequence chart) 

9.2.7 Session release initiated by IM-MGW 
9.2.7.1 BICC 



9.2.7.1.1 



Session release in the CS network side 



Upon receiving from the IM-MGW a "Bearer Released" procedure (signal la and 2a in figure 46) or "IMS Bearer 
Released" procedure (signal lb and 2b in figure 46) or a "MGW Out-of-Service" procedure indicating an immediate 
release (H248 ServiceChangeMethod="Forced") (not depicted in figure 46), the MGCF shall send a REL message to 
the succeeding node on the CS network side (signal 3 in figure 46). Once the succeeding node has responded with the 
RLC message (signal 5 in figure 46), the MGCF shall release the resources for the CS network side in the IM-MGW, 
unless the "MGW Out-of-Service" procedure was received. If any resources were seized in the IM-MGW, the MGCF 
shall use the "Release Termination" procedure to indicate to the IM-MGW that the CS network side bearer termination 
shall be removed (signals 6 and 7 in figure 46). 

NOTE: Other actions related to MGW Out-Of-Service procedure is defined in 3GPP TS 23.205 [27]. 



9.2.7.1.2 



Session release in the IM CN subsystem side 



Upon receiving from the IM-MGW a "Bearer Released" procedure (signals la and 2a in figure 46) or "IMS Bearer 
Released" procedure (signal lb and 2b in figure 46) or a "MGW Out-of-Service" procedure indicating an immediate 
release (H248 ServiceChangeMethod="Forced") (not depicted in figure 46), the MGCF shall send a BYE/CANCEL 
message to the IM CN subsystem side (signal 4 in figure 46) Upon receiving from the IM-MGW a "Bearer Released" 
procedure or "IMS Bearer Released" procedure, the MGCF shall also release the resources in the IM-MGW serving the 
relevant Mb interface connection by using the "Release IMS Termination" procedure (signals 8 and 9 in figure 46). The 
MGCF shall also expect to receive a 200 OK [BYE] message from the IM CN subsystem side (signal 10 in figure 46). 

NOTE: Other actions related to MGW-Out-Of-Service procedure is defined in 3GPP TS 23.205 [27] 

9.2.7.1 .3 Message sequence chart 

Figure 46 shows the message sequence chart for the session release initiated by the IM-MGW. 
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Bearer Released 



IMS Bearer 
Released 



4. SIP: BYE 



MGCF 



Release Termination 



Release IMS Termination 



10.S!P:200OK[BYE] 



IM-MGW 



1 a. H.248 : Notify.req [Context ID = C1 , Termination ID = T2] 



2a. H.248 : Notify.resp [Context ID = C1 , Termination ID = 12] 



1b. H.248 : Notify.req [Context ID = CI, Termination ID = T1] 



2b. H.248 : Notify.resp [Context ID = CI, Termination ID = T1] 



3. BICC: REL 



5. BICC: RLC 



6. H.248 : SUB.req [Context ID = CI, Termination ID = T2] 



7. H.248 : SUB.resp [Context ID = CI , Termination ID = T2 ] 



8. H.248 : SUB.req [Context ID = CI, Termination ID = T1] 



9. H.248 : SUB.resp [Context ID = CI, Termination ID = T1] 



Figure 46: Session release initiated by the IIVI-IVIGW for BICC (message sequence chart) 



9.2.7.2 



ISUP 



9.2.7.2.1 



Session release in the CS networl< side 



Upon receiving from the IM-MGW a "Termination Out-of-Service" procedure indicating an immediate release (signals 
la and 2a in figure 47), a "Bearer Released" procedure (signal lb and 2b in figure 47), a "IMS Bearer Released" 
procedure (signal Ic and 2c in figure 47) or a "MGW Out-of-Service procedure" (not depicted in figure 47) indicating 
an immediate release (H248 ServiceChangeMethod="Forced") the MGCF shall send a REL message to the succeeding 
node (signal 3 in figure 47). Upon receiving from the IM-MGW a "Termination Out-of-Service" message procedure 
indicating an immediate release or a "Bearer Released" procedure, the MGCF shall also release the resources for the 
corresponding CS network side termination(s) in the IM-MGW. If any resources were seized in the IM-MGW, the 
MGCF shall use the "Release TDM Termination" procedure to indicate to the IM-MGW that the CS network side 
bearer termination can be removed (signals 7 and 8 in figure 47). The MGCF also expects to receive a RLC message on 
the CS network side (signal 9 in figure 47) before the circuit is reselectable. 

NOTE: Other actions related to "MGW-Out-Of-Service" procedure are defined in 3GPP TS 23.205 [27]. 



9.2.7.2.2 



Session release in the IM CN subsystem side 



Upon receiving from the IM-MGW a "Termination Out-of-Service" procedure indicating an immediate release (signal 
la and 2a in figure 47) on the CS termination in the context, a "Bearer Released" procedure (signal lb and 2b in figure 
47), an "IMS Bearer Released" procedure (signal Ic and 2c in figure 47) or a "MGW Out-of-Service procedure" (not 
depicted in figure 47) indicating an immediate release, (H248 ServiceChangeMethod="Forced") the MGCF shall send a 
BYE/CANCEL message to the IM CN subsystem side (signal 4 in figure 47). Upon receiving from the IM-MGW a 
"Termination Out-of-Service" procedure indicating an immediate release on the CS termination in the context, a 
"Bearer Released" procedure or an "IMS Bearer Released" procedure, the MGCF shall also release the resources in the 
IM-MGW for the corresponding terminations towards the IM CN subsystem using the "Release IMS Termination" 
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procedure (signals 5 and 6 in figure 47). The MGCF also expects to receive a 200 OK [BYE] message from the IM CN 
subsystem side (signal 10 in figure 47). 

NOTE: Other actions related to "MGW-Out-Of-Service" procedure are defined in 3GPP TS 23.205 [27]. 

9.2.7.2.3 Message sequence chart 

Figure 47 shows the message sequence chart for the session release initiated by the IM-MGW. 



Termination 
Out-of-Service 



or 
Bearer Released 

or 

IIVIS Bearer 
Released 

4. SIP: BYE 



Release IMS 
Termination 



Release TDM 
Termination 



10.S!P:200OK[BYE] 



IM-MGW 



1 a. H.248 : ServiceChange.req 
[Context ID = 01 , Termination ID = T2] 



2a. H.248 : ServiceChange.resp 
[Context ID = C1 , Termination ID = T2] 



1 b. H.248 : Notify.req [Context ID = C1 , Termination ID = T2] 



2b. H.248 : Notify.resp [Context ID = C1 , Termination ID = T2] 



1c. H.248 : Notify.req [Context ID = CI , Termination ID = T1] 



2c. H.248 : Notify.resp [Context ID = CI, Termination ID = T1] 



3. ISUP: REL 



5. H.248 : SUB.req [Context ID = CI , Termination ID = T1 ] 



6. H.248 : SUB.resD [Context ID = CI, Termination ID = T1] 



7. H.248 : SUB.req [Context ID = CI .Termination ID = T2] 



8. H.248 : SUB.resp [Context ID = CI , Termination ID = T2 ] 



9. ISUP: RLC 



Figure 47: Session release initiated by the IM-MGW for ISUP (message sequence chart) 

9.2.8 HancJIing of RTP telephone events 

DTMF digits, telephony tones and signals (telephone events) can be transferred using different mechanisms. For the IM 
CN Subsystem, 3GPP TS 24.229 [9] defines the usage of the RTP payload format defined for DTMF Digits, Telephony 
Tones and Telephony Signals in RFC 4733 [105]. When BICC signalling is used in the CS network, telephony signals 
may be sent either inband or out-of-band as defined in ITU-T Recommendation Q. 1902.4 [30] and in ITU-T 
Recommendation Q.765.5 [35]. If ISUP signalling is used the DTMF tones are sent inband. The following paragraphs 
describe the Mn interface procedures to transfer DTMF between RTP format defined in RFC 4733 [105] and the CS 
CN. 

Before the actual usage of the telephony signals can occur the sending/receiving of telephone events need to be agreed 
with the SDP offer-answer mechanism defined in RFC 3264 [36]. The outcome of the negotiation can be e.g. that no 
telephone events are sent in RTP payload, telephone events are sent only in one direction or in both directions. If the 
outcome of the negotiation is that RTP payload telephone-events are sent in both directions, the IM-MGW may 
nevertheless be configured to interwork only mobile originated telephone-events. 

When the offer-answer mechanism based session parameters negotiation results in an agreement that telephone events 
are sent in the RTP payload and the needed preconditions are fulfilled, telephone events can be sent in RTP payload. 
This negotiation can be done at call control signalling phase or during an ongoing call. 
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If the MGCF and IM-MGW support the reception and/or transmission of the RTP MIME type "telephone event" (as 
defined in RFC 4733 [105]) with the IMS, the following appHes: 

For CS Network Originating Sessions, the MGCF shall include the MIME type "telephone events" with default 
events in the first SDP offer. After the usage of telephone events is agreed in the subsequent offer-answer 
parameter exchanges and the needed preconditions defined in RFC 3312 [37] are fulfilled, telephone events can 
be sent as RTP payload. 

In case of IM CN Subsystem Originating Sessions, the MGCF shall accept the MIME type "telephone events" 
with default events in any SDP answer when it received such an offer. 

9.2.8.1 Sending DTMF digits out-of-band to CS CN (BICC) 

For the IM CN subsystem terminated session, the MGCF shall use the "Configure IMS Resources" procedure as 
described in subclause 9.2.3. For the IM CN subsystem originating session, the MGCF shall use the "Reserve IMS 
Connection Point and Configure Remote Resources" procedure as described in subclause 9.2.2. If DTMF is supported, 
the MGCF shall include "telephone event" along with the selected speech codecs within the "local IMS resources" 
Parameter of these procedures. The same termination shall be used to receive and transmit DTMF and speech of the 
same call. 

Furthermore, the MGCF shall use the "Detect IMS RTP Tel Signal" procedure to request the MGW to detect incoming 
telephone events from the IMS and notify the MGCF about the detected events. The MGW shall use the "Notify IMS 
RTP Tel Event" procedure for this notification. The termination used to receive DTMF shall be placed in the same 
context used for the speech of the same call. The MGCF shall request to be notified when the MGW detects the end of a 
digit and may also request to be notified when the MGW detects the start of a digit. An IM-MGW not supporting the 
notification about the detection of the start of a digit may ignore the request to provide this notification. If the IM-MGW 
received a "Detect IMS RTP Tel Event" procedure for a termination, the IM-MGW shall not forward inband to the CS 
network any DTMF received at this termination. 

Figure 48 shows an example message sequence chart when a DTMF digit is received from the IM CN subsystem in the 
RTP payload and the MGCF has requested to be notified only about the detection of the end of a digit. Figure 48a 
shows an example message sequence chart when a DTMF digit is received from the IM CN subsystem in the RTP 
payload and the MGCF has requested to be notified about the detection of the start and the end of a digit. 
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IM-MGW 



Configure IMS Resources 
or 

Reserve IMS Conection Point 

and configure Remote 

Resources, 

Detect IMS RTP Tel Event 



Notify_IMS_RTP_Tel_Event 



MGCF 



1 . H.248 Add/Mod. req 

[Context ID = C1, Termination ID = T1, 

Codec = "teiephone event, AMR", 

Notify iMS RTP Tei Event ("End tone detected") 



2. H.248 Add/Mod. resD [Context ID = 01. Termination ID=T1] . 



8. RTP encoded new DTMF event 

(tone-event, end=0, duration=x) 



9. RTP encoded continued DTMF event 

(tone-event, end=1 , duration= Duration) 



10. H.248 Notify.ind 

[Context ID = CI , Termination ID = T1 , Tone-ID, 
Event="End tone detected". Duration] 



11. H.248 Notify. resp[Context ID = C1, Termination iD = T1] 



12. BIGG APM (Actind= Start signal notify, signal-type, duration) 



13. BIGG APM (Actlnd=Start signal acl<) 



> 



1 Digit 



J 



Figure 48: Activation of notification of DTIVIF digits received in RTP and examples of sending the 
digits out-of-band to CS CN, a wliole digit received by IM-MGW before sending further (message 

sequence chart) 
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IM-MGW 



Configure IMS Resources 

or 

Reserve IMS Conection Point 

and configure Remote 

Resources, 

Detect IMS RTP Tel Event 



Notify_IMS_RTP_Tel_Event 



MGCF 



1 . H.248 Add/Mod. req 

[Context ID = CI , Termination ID = T1 , 
Codec = "telephone event, AIVIR", 
Notify IMS RTP Tel Event ("Start tone detected", 
"End tone detected") 



2. H.248 Add/IVIod.resp [Context ID = C1. Termination ID=T11 . 



3. RTP encoded new DTMF event 

(tone-event, end=0, duration=x) 



4. H.248 Notify.ind 

[Context ID = CI , Termination ID = T1, ToneJD, 
Event="Start tone detected"] 



5. H.248 Notify.resp[Context ID = C1 , Termination ID = T1] 



Notify_IMS_RTP_Tel_Event 



6. BICC ARM (Actlnd=Start signal notify, signal-type) 



7. BICC APM (Actlnd=Start signal acl<) 



8. RTP encoded new DTMF event 

(tone-event, end=0, duration=y) 



9. RTP encoded continued DTIVIF event 

(tone-event, end=1, duration=Duration) 



10. H.248 Notify.ind 

[Context ID = CI , Termination ID = T1 , Tone-ID, 
Event="End tone detected". Duration] 



11. H.248 Notify. resp[Context ID = CI, Termination ID = T1] 



12. BICC APIVI (Actlnd=Stop signal notify) 



13. BICC APIVI (Actlnd=Stop signal acl<) 



1 Digit 



^ • •• 



Figure 48a: Activation of notification of DTIVIF digits received in RTP and examples of sending the 
digits out-of-band to CS CN, IM-MGW starts sending the digit further when the start of the digit is 

recognized (message sequence chart) 



9.2.8.2 



Sending and receiving DTMF digits inband to/from CS CN (ISUP or BICC) 



For the IM CN subsystem terminated session, the MGCF shall use the "Configure IMS Resources" procedure as 
described in subclause 9.2.3. For the IM CN subsystem originating session, the MGCF shall use the "Reserve IMS 
Connection Point and Configure Remote Resources" procedure as described in subclause 9.2.2. If DTMF is supported 
and the MGCF wants to configure the IM_MGW to send and receive DTMF to/from the CS network side, the MGCF 
shall include "telephone event" along with the selected speech codecs within the "local IMS resources" parameter of 
these procedures to request the MGW to detect incoming telephone events and transform them into speech signals on 
the CS side and shall not apply the "Detect IMS RTP Tel Event" procedure. When receiving this configuration, an 
MGW supporting DTMF shall detect DTMF encoded according as RTP Tel Event and transform this into DTMF tones 
encoded within the speech codec used at the CS CN network and may in addition optionally detect incoming telephone 
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events received inband from the CS CN network and transform them into telephone events on the IMS side. The same 
termination shall be used to receive and transmit DTMF and speech of the same call. 

Figure 49 shows the message sequence chart to configure the IM-MGW to receive DTMF detection on the IMS side 
and transfer the DTMF inband on the CS side. When receiving this configuration, the IM-MGW may in addition 
optionally detect DTMF inband on the CS side and transmit DTMF on the IMS side. 



IM-MGW 




MGCF 




1 . H.248 Add/Mod. req 

[Context ID = C1 , Termination ID = T1 , 

Codec = "telephone event, AMR",] 




Dint 


2. H.248 Add/Mod. resp [Context ID = C1, Termination ID = T1] 










w 





Configure IMS Resources 

Or 

Reserve IMS Conection Point 

and configure Remote 

Resources 



Figure 49: Activation of processing of DTIVIF digits received in RTP for sending the digits inband to 

CS CN (message sequence chart) 



9.2.8.3 



Receiving DTMF digits out-of-band from CS CN (BICC) 



For the IM CN subsystem terminated session, the MGCF shall use the "Configure IMS Resources" procedure as 
described in subclause 9.2.3. For the IM CN subsystem originating session, the MGCF shall use the "Reserve IMS 
Connection Point and Configure Remote Resources" procedure as described in subclause 9.2.2. If DTMF is supported, 
the MGCF shall include "telephone event" along with the selected speech codecs within the "local IMS resources" 
Parameter of these procedures. The same termination shall be used to receive and transmit DTMF and speech of the 
same call. 

Furthermore, the MGCF shall use the "Send IMS RTP Tel Event" and may use the "Stop IMS RTP Tel Event" 
procedures to request the MGW to play out DTMF to the IM CN subsystem whenever it receives out-of-band DTMF 
indications from the BICC network. 

Figure 49a shows an example message sequence chart when DTMF digits are transmitted to the IM CN subsystem in 
the RTP payload. For the first digit, the received APM message contains all information including the duration and only 
a single notification is received. For the second digit, the start and the end of the DTMF digit are notified separately. 
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IM-MGW 



Configure IMS Resources 

or 

Reserve IMS Conection Point 

and configure Remote 

Resources, 

Detect IMS RTP Tel Event 



Send IMS RTP Tel Event 



Send IMS RTP Tel Event 



Stop_IMS_RTP_Tel_Event 



MGCF 



1. H.248 Add/Mod. req 

[Context ID = C1 , Termination ID = T1 , 
Codec = "teleplnone event, AMR", 
Notify IMS RTP Tel Event ("Start tone detected", 
"End tone detected") ] 



2. H.248 Add/Mod. resD [Context ID = C1 . Termination ID =T1L 



3. BICC APM(Actlnd=Start signal notify, signal-type, duration) 



4. BICC ARM (Actlnd=Start signal ack) 



5. H.248 Mod.ind 

[Context ID = C1 , Termination ID = T1 , Tone-Id, 
SignalType=TimeOut, Duration] 



6. H.248 Mod.resp[Context ID = C1, Termination ID = T1] 



7. RTP encoded new DTMF event 

(tone-event, end=0, duration=x) 

7. RTP encoded new DTMF event 
(tone-event, end=1, duration) 



8. BICC ARM (Actlnd==Start signal notify, signal-type) 



9. BICC ARM (Actlnd=Start signal ack) 



10. H.248 Mod.ind 

[ Context ID = C1 , Termination ID = T1 , ToneJD, 
^ SianalTvpe=0n/0ff1 



11. H.248 Mod.resp[Context ID = C1, Termination ID = T1] 



12. RTP encoded new DTMF event 

(tone-event, end=0, duration=x) 



13. RTP encoded new DTMF event 

(tone-event, end=0, duration=y) 



14. BICC ARM (Actlnd=Stop signal notify) 



15. BICC ARM (Actlnd=Stop signal ack) 



16. H.248 Mod.ind 

[Context ID = C1, Termination ID = T1] 



17. H.248 Mod.resp[Context ID = CI , Termination ID = T1] 



187. RTP encoded continued DTMF event 
(tone-event, end=1, duration) 



Digit 1 



Digit 2 



Figure 49a: Examples of receiving DTIVIF digits out-of-band from the CS CN 
and transmitting them in RTP (message sequence chart) 
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9.2.9 Session hold initiated from IM CN subsystem 

The network model in the subclause 9.2.1 shall apply here. 

Hold request 

When the IMS network makes a hold request by sending an UPDATE or re-INVITE message (signal 1 of figure 50), 
the MGCF shall request the IM-MGW to suspend sending media towards the IMS side by changing the through- 
connection of the IM CN subsystem side termination to "not through-connected" (signal 2 of figure 50). If the IMS side 
provides modified SDP RR or RS bandwidth modifiers, as specified in IETF RFC 3556 [59], within the hold request, 
the MGCF shall use the Configure IMS Resources Mn procedure to forward this information to the IM-MGW (not 
depicted in figure 50, but may be combined with signal 2). The MGCF shall send a CFG (Hold) message to the 
succeeding CS network node to indicate that the session is on hold (signal 4 of figure 50). Simultaneously a SIP 
message acknowledging the Hold request is sent to the IMS side (signal 7 of figure 50, acknowledged by signal 7. a if 
the INVITE method is used). Announcements may be applied to the party on hold, depending on the held party"s status, 
using the Play Announcement procedure (for BICC) or the Play TDM Announcement procedure (for ISUP, signal 5 in 
figure 50). The hold operation shall not block RTCP flows. 

Resume request 

When the IMS network makes a request to retrieve the session on hold by sending an UPDATE or re-INVITE message 
(signal 8 of figure 50), the MGCF shall request the IM-MGW to re-establish communication towards the IMS network 
by changing the through-connection of the IM CN subsystem side termination to both- way through-connected (signal 
1 1 of figure 50). If the IMS side provides modified SDP RR or RS bandwidth modifiers, as specified in IETF RFC 3556 
[59], within the retrieve request, the MGCF shall use the Configure IMS Resources Mn procedure to forward this 
information to the IM-MGW (not depicted in figure 50, but may be combined with signal 11). Possible announcements 
to the party on hold shall be stopped using the Stop Announcement procedure (for BICC) or the Stop TDM 
Announcement procedure (for ISUP, signal 9 in figure 50). The MGCF shall send a CPG (Retrieve) message to the 
succeeding CS network node to indicate that the session is retrieved (signal 13 of figure 50). 

Message sequence chart 

Figure 50 shows the message sequence chart for the call hold and retrieval procedures. 
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MGCF 




IM-MGW 




1. SIP: UPDATE/INVITE SDP, 
a=sendonly/inactive 














Change Through- 
Cnnnprtinn— Inartivp 


2. H.248: MOD.req 

[Context ID = CI, Termination ID = T1] 






3. H.248: MOD.resp 

[Context ID = CI, Termination ID = T1] 






4. BICC/ISUP: CPG (Hold) 




Play TDM 


5. H.248: MOD.req 

[Context ID = CI , Termination ID = T2] 






Announcement 


6. H.248: MOD.resp 

[Context ID = CI , Termination ID = T2] 




7. SIP: 200 OK fSDP] 


9. H.248: MOD.req 

[Context ID = CI , Termination ID = T2] 




7.a SIP: ACK (if INVITE is used) 




8. SIP: UPDATE/INVITE [SDP, 
a=sendrecv/recvonly] 








Stop TDM 
Announcement 


10. H.248: MOD.resp 

[Context ID = CI , Termination ID = T2] 






11. H.248: MOD.req 

[Context ID = CI, Termination ID = T1] 




Change Ttirougti- 
Connection=Both 


12. H.248: MOD.resp 

[Context ID = CI, Termination ID = T1] 






13. BICC/ISUP: CPG (Retrieve) 




14. SIP:200OKfSDPl 








14.a SIP: ACK (if INVITE is used) 






^^ 





Figure 50 Session hold from IIV! CN subsystem 

9.2.10 Session Inold initiated from CS network 

When an MGCF receives a CPG message with a "remote hold" Generic notification indicator (signal 1 of figure 51), the 
MGCF forwards the hold request by sending an UPDATE or re-INVITE message containing SDP with "sendonly" or 
"inactive" media (signal 4 of figure 51). 

When an MGCF receives a CPG message with a "remote retrieval" Generic notification indicator (signal 6 of figure 
51), the MGCF forwards the resume request by sending an UPDATE or re-INVITE message containing SDP with 
"send re cv" or "recvonly" media (signal 9 of figure 51). 

If the MGCF receives a CPG with "remote hold" or "remote retrieval" before answer, it shall forward the request using 
an UPDATE message. If the MGCF receives a CPG with "remote hold" or "remote retrieval" after answer, it should 
forward the request using re-INVITE but may use UPDATE. 

If link aliveness information is required at the IM-MGW while the media are on hold, the MGCF should provide to the 
modified SDP RR and RS bandwidth modifiers specified in IETF RFC 3556 [59] within the SDP offers in the UPDATE 
or re-INVITE messages holding and retrieving the media to temporarily enable RTCP while the media are on hold, as 
detailed in subclause 7.4 of 3GPP TS 26.236 [32]. If no link aliveness information is required at the IM-MGW, the 
MGCF should provide the SDP RR and RS bandwidth modifiers previously used. 
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The interworking does not impact the user plane, unless the MGCF provides modified SDP RR and RS bandwidth 
modifiers in the UPDATE or re -INVITE messages. If the MGCF provides modified SDP RR and RS bandwidth 
modifiers in the UPDATE or re-INVITE messages, the MGCF shall also provide modified SDP RR and RS bandwidths 
to the IM-MGW using the Configure IMS Resoureces procedures (signals 2-3 and 7-8 of figure 51). 

Message sequence chart 

Figure 51 shows the message sequence chart for the call hold and retrieval procedures. 



MGCF 



1. BICC/ISUP : CPG (Hold) 



Configure IMS 

Resources 

(optional) 



6. BICC/ISUP : CPG (Retrieve) 



Configure IMS 

Resources 

(optional) 



IM-MGW 



2. H.248 : MOD.req 

[Context ID = C1 , Termination ID = T1] 



3. H.248 : MOD.resp 

[Context ID = C1, Termination ID = T1] 



4. S!P: UPDATE/INVITE [SDP, a=sendonly/inactive] 



5. S!P: 200 OK [SDP] 



5.a SIP: ACK (if INVITE is used) 



7. H.248 : MOD.req 

[Context ID = C1 , Termination ID = T1] 



8. H.248 : MOD.resp 

[Context ID = C1, Termination ID = T1] 



9. S!E: UPDATE/INVITE [SDP, a=sendrecv/recvonly] 



10. SIP:200OKrSDP1 



10.a S!P: ACK (if INVITE is used) 



Figure 51 Session hold from CS networit 

9.3 Mn Signalling procedures 

This subclause describes of logical signalling procedures (i.e. message identifiers are not part of the protocol) between 
the MGCF and IM-MGW. The procedures within this subclause are intended to be implemented using the standard 
H.248 procedure as defined in] ITU recommendation H.248. 1 [2] with appropriate parameter combinations. 

9.3.1 Procedures related to terminations towards the IIVI CN Subsystem 

A mapping of the procedures defined here to H.248 procedures and parameters is provided in 3GPP TS 29.332 [15]. 
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9.3.1 .1 Reserve IMS connection point 

This procedure is used to reserve local connection addresses and local resources. 

Table 25: Procedures toward the IM Subsystem: Reserve IMS connection point 



Procedure 


Initiated 


Information 
element name 


Information 
element 
required 


Information element description 


Reserve IMS 

Connection 

Point 


MGCF 


Context/Context 
Request 


M 


This information element indicates the 
existing context or requests a new context 
for the bearer termination. 


IMS Termination 
Request 


M 


This information element requests a new 
IMS termination for the bearer to be 
established. 


Local IMS 
Resources/ 


M 


This information element indicates the 
resource{s) (i.e. codecs) for which the IM- 
MGW shall be prepared to receive user 
data, 


IP Interface Type 





This information element indicates the used 
interface type 


ReserveValue 





This information element indicates if multiple 
local IMS resources are to be reserved. 


Local Connection 
Addresses Request 


M 


This information element requests an IP 
address and port number on the IM-MGW 
that the remote end can send user plane 
data to. 


Notify termination 
heartbeat 


M 


This information element requests 
termination heartbeat indications. 


Notify Released 
Bearer 





This information element requests a 
notification of a released bearer. 


IP Realm Identifier 





This information element indicates the IP 
realm of the IP termination. 


Reserve IIVIS 

Connection 

Point Acl< 


IM-MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


IMS Termination 


M 


This information element indicates the IMS 
termination where the command was 
executed. 


Local IMS Resources 


M 


This information element indicates the 
resources that the IM-MGW has reserved to 
receive the user plane data from the IMS. 


Local Connection 
Addresses 


M 


This information element indicates the IP 
address and port on the IM-MGW that shall 
receive user plane data from IMS. 
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9.3.1.2 Configure IMS resources 

This procedure is used to select multimedia-processing resources for an Mb interface connection. 

Table 26: Procedures toward the IM Subsystem: Select Local, 
Select Remote IMS Processing Resource 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Configure IMS 
Resources 


MGCF 


Context 


M 


This information element indicates the 
existing context. 


IIVIS Termination 


M 


This information element indicates the 
existing bearer termination. 


Local IMS Resources 





This information element indicates the 
resources (i.e. codec) that the IM-MGW may 
use on the reception of user plane data. 


Remote IMS 
Resources 


M 


This information element indicates the 
resources (i.e. codec) that the IM-MGW may 
send user plane data to. 


Local Connection 
Addresses 





This information element indicates the IP 
address and port on the IM-MGW that the 
IMS user can send user plane data to. 


Remote Connection 
Addresses 


M 


This information element indicates the IP 
address and port that the IM-MGW can send 
user plane data to. 


IP Interface Type 





This information element indicates the used 
interface type 


Reserve Value 





This information element indicates if multiple 
IMS resources are to be reserved. 


Remote Connection 

Addresses Source 

Filter 





This information element indicates an 
optional source filter restricting the IP 
addresses and ports that the IM-MGW shall 
accept as source for incoming user plane 
data. If this information element is set, the 
IM-MGW shall silently discard incoming user 
plane data from disallowed sources. 


Configure IIVIS 

Resources 

Acl< 


IIVI-MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


IMS Termination 


M 


This information element indicates the IMS 
termination where the command was 
executed. 


Local IMS Resource 





This information element indicates the 
resources that the IM-MGW has reserved to 
receive the user plane data from the far end. 


Remote IMS 
Resource 


M 


This information element indicates the 
resource (i.e. codec) that the IM-MGW shall 
use to send user data to. 


Local Connection 
Address 





This information element indicates the IP 
address and port on the IM-MGW that the 
remote end can send user plane data to. 


Remote Connection 
Address 


M 


This information element indicates the IP 
address and port that the IM-MGW can send 
user plane data to. 



9.3.1 .3 Reserve IMS Connection point and configure remote resources 

This procedure is used to reserve multimedia-processing resources for an Mb interface connection. 
Table 27: Procedures toward the IM Subsystem: reserve local, reserve remote IMS connection point 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 
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Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Reserve IMS 

Connection 

Point and 

Configure 

Remote 

Resources 


MGCF 


Context/Context 
Request 


M 


This information element indicates the 
existing context or requests a new context 
for the bearer termination. 


IMS Termination/IMS 
Termination Request 


M 


This information element indicates the 
existing bearer termination or requests a 
new IMS termination for the bearer to be 
established. 


Local IMS Resources 


M 


This information element indicates the 
resource{s) (i.e. codecs) for which the IM- 
MGW shall be prepared to receive user 
data, 


Remote IMS 
Resources 


M 


This information element indicates the 
resources (i.e. codec) that the IM-MGW 
shall use to send user data in the IMS. 


IP Interface Type 





This information element indicates the used 
interface type 


Reserve Value 





This information element indicates if multiple 
IMS resources are to be reserved. 


Local Connection 
Address request 


M 


This information element requests an IP 
address and a port number on the IM-MGW 
that the remote end can send user plane 
data to. 


Remote Connection 
Addresses 


M 


This information element indicates the IP 
address and ports at an IMS user that the 
IM-MGW can send user plane data to. 


Notify termination 
heartbeat 


M 


This information element requests 
termination heartbeat indications. 


Notify Released 
Bearer 





This information element requests a 
notification of a released bearer. 


IP Realm Identifier 





This information element indicates the IP 
realm of the IP termination. 


Reserve IMS 

Connection 

Point and 

Configure 

Remote 

Resources Ack 


IM-MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


IMS Termination 


M 


This information element indicates the IMS 
termination where the command was 
executed. 


Local IMS Resources 


M 


This information element indicates the 
resources that the IM-MGW has reserved to 
receive the user plane data from IMS. 


Remote IMS 
Resources 


M 


This information element indicates the 
resource (i.e. codec) that the IM-MGW shall 
use to send user data. 


Local Connection 
Addresses 


M 


This information element indicates the IP 
address on the IM-MGW that shall receive 
user plane data from the IMS. 



9.3.1 .4 Release IMS termination 

This procedure is used by the MGCF to release a termination towards the IMS and free all related resources. 
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Table 28: Release IMS termination 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Release IMS 
Termination 


MGCF 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Bearer Termination 


M 


This information element indicates the 
bearer termination to be released. 


Release IMS 
Termination Ack 


IM-MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the 
bearer termination where the command was 
executed. 



9.3.1.5 



Detect IMS RTP Tel event 



This procedure is used by the MGCF to request from the MGW the detection of telephony events signalled within RTP 
according to RFC 4733 [105] and the notification of received telephony events. This procedure is the same as that is 
defined in the subclause ""Detect DTMF"" in 3GPP TS 23.205 [27]. 



Table 29: VOID 



9.3.1.6 



Notify IMS RTP Tel event 



This procedure is used by the MGW to notify the MGCF about the detection of telephony events signalled within RTP 
according to RFC 4733 [105]. This procedure is the same as that defined in the subclause "Report DTMF" in 
3GPPTS 23.205 [27]. 

Table 30: VOID 



9.3.1.7 



Void 



9.3.1.8 



Send IMS RTP Tel event 



This procedure is used by the MGCF to request from the MGW to signal a telephone event within RTP according to 
RFC 4733 [105]. This procedure is the same as that defined in the subclause "Send DTMF" in 3GPP TS 23.205 [27]. 



9.3.1.9 



Stop IMS RTP Tel event 



This procedure is used by the MGW to request from the MGW to stop signalling a telephone event within RTP 
according to RFC 4733 [105]. This procedure is the same as that defined in the subclause "Stop DTMF" in 
3GPPTS 23.205 [27]. 
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9.3.1 .10 Termination heartbeat indication 

This procedure is used to report indication of hanging termination. 

Table 30a: Procedures between (G)MSC server and MGW: Hanging termination indication 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Termination 
heartbeat 
indication 


MGW 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Bearer Termination 


M 


This information element indicates the 
bearer termination for which the termination 
heartbeat is reported. 


Termination heartbeat 


M 


Hanging Termination event, as defined in 
3GPPTS 29.332 [15]. 


Termination 

heartbeat 

indication Ack 


(G)MSC-S 


Context 


M 


This information element indicates the 
context where the command was executed. 



9.3.1.11 



IMS Bearer Released 



This procedure is used by the IM-MGW to indicate towards the MGCF that an error occurred on an IMS termination 
which requires the release of the termination. This procedure is the same as that defined in the subclause "Bearer 
Released" in 3GPP TS 23.205 [27]. 



9.3.1.12 



End IMS RTP Tel event 



This procedure is used by the MGCF to indicate to the IM-MGW to stop detection of telephony events signalled within 
RTP according to IETF RFC 4733 [105]. This procedure is the same as that is defined in the subclause "Stop Detect 
DTMF" in 3GPP TS 23.205 [27]. 



9.3.1.13 



IMS Send Tone 



This procedure is used by the MGCF to order the IM-MGW to generate a tone at termination towards IMS. This 
procedure is the same as that defined in the subclause "Send Tone" in 3GPP TS 23.205 [27]. 

9.3.1.14 IMS Stop Tone 

This procedure is used by the MGCF to order the IM-MGW to stop generating a tone at a termination towards IMS. 
This procedure is the same as that defined in the subclause "Stop Tone" in 3GPP TS 23.205 [27]. 

9.3.1.15 IMS Tone Completed 

This procedure is used by the IM-MGW to indicate to the MGCF that a tone has finished being generated at a 
termination. This procedure is the same as that defined in the subclause "Tone Completed" in 3GPP TS 23.205 [27]. 

9.3.2 Procedures related to a termination towards an ISUP network 

A mapping of the procedures defined here to H.248 procedures and parameters is provided in 3GPP TS 29.332 [15]. 

9.3.2.1 Reserve TDM circuit 

This procedure is used by the MGCF to reserve a TDM circuit in the IM-MGW towards the preceding/succeeding CS 
network element. 
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Table 31 : Reserve TDM circuit procedure 



Procedure 


initiated 


Information element 
name 


information 
element 
required 


information element description 


Reserve TDM 
Circuit 


MGCF 


Context/Context 
Request 


M 


This information element indicates the 
existing context or requests a new context 
for the bearer termination. 


Bearer Termination 


M 


This information element indicates the 
physical bearer termination for the TDIVI 
circuit. 


Bearer Service 
Characteristics 


M 


This information element indicates the 
bearer service requested by the user. 


Notify termination 
heartbeat 





This information element requests 
termination heartbeat indications. 


Notify Released 
Bearer 





This information element requests a 
notification of a released bearer 


Reserve Circuit 
Acl< 


IIVI-MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 



9.3.2.2 



Change TDM through-connection 



This procedure is used by the MGCF to modify the through-connection (forward, backward, both-way, inactive) of a 
TDM termination at the IM-MGW towards the PSTN. 

This procedure is the same as Change Through Connection in TS 23.205 [27]. 

9.3.2.3 Activate TDM voice-processing function 

This procedure is used by the MGCF to activate or de-activate a voice processing function of a TDM termination at the 
IM-MGW towards the PSTN. This voice processing function may include a cancellation for electronic echoes. 

This procedure is the same as Activate Voice Processing Function in 3GPP TS 23.205 [27]. 

9.3.2.4 Send TDM tone 

This procedure is used by the MGCF to order the IM-MGW to generate a tone at a TDM termination towards the 
PSTN. 

This procedure is the same as Send Tone in 3GPP TS 23.205 [27]. 

9.3.2.5 Stop TDM tone 

This procedure is used by the MGCF to order the IM-MGW to stop generating a tone at a TDM termination towards the 
PSTN. 

This procedure is the same as Stop tone in 3GPP TS 23.205 [27]. 

9.3.2.6 Play TDM announcement 

This procedure is used by the MGCF to order the IM-MGW to generate an announcement at a TDM termination 
towards the PSTN. The MGCF may request a notification that the announcement is completed. This procedure is the 
same as Play Announcement in 3GPP TS 23.205 [27]. This procedure is optional. 



9.3.2.7 



TDM announcement completed 



This procedure is used by the IM-MGW to notify the MGCF that an announcement at a TDM termination towards the 
PSTN is completed. This procedure is the same as Announcement Completed in 3GPP TS 23.205 [27]. This procedure 
is optional. 
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9.3.2.8 



Stop TDM announcement 



This procedure is the same as Stop Announcement 3GPP TS 23.205 [27]. This procedure is used by the MGCF to order 
the IM-MGW to stop generating an announcement at a TDM termination towards the PSTN. This procedure is optional. 



9.3.2.9 



Continuity check 



This procedure is used by the MGCF to order the IM-MGW to generate a continuity check tone at a TDM termination 
towards the PSTN and to inform the MGCF about the result of the continuity check as soon as the continuity check tone 
is received or a time-out occurs. This procedure is optional. 

Table 32: Continuity checit procedure 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Continuity 
checl< 


MGCF 


Context/Context 
Request 


M 


This information element indicates the 
existing context or requests a new context 
for the bearer termination. 






TDIVI Termination 


IVI 


This information element indicates the 
existing bearer termination 






Request for continuity 
tone sending 


M 


This information request the IM-MGW to 
apply the continuity check procedure on the 
indicated TDM termination 






Request for continuity 
checl< tone detection 


M 


This information request the IM-MGW to 
inform e continuity check procedure on the 
indicated TDM termination 



9.3.2.10 Continuity check verify 

This procedure is used by the IM-MGW to indicate towards the MGCF that the continuity check at a TDM termination 
towards the PSTN has been completed and to return the result of the check: success or failure. This procedure is 
optional. 

Table 33: Continuity check verify procedure 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Continuity 
check 
Verify 


IM-MGW 


Context/t 


M 


This information element indicates the 
context where the command was executed. 






TDM Termination 


M 


This information element indicates the TDM 
termination involved in the procedure 






Outcome of the 
continuity check 


M 


This information element indicates the 
outcome of the continuity check 
(successful/unsuccessful) 



9.3.2.1 1 Continuity check response 

This procedure is used by the MGCF to order the IM-MGW to loop back an incoming continuity check tone at a TDM 
termination towards the PSTN. This procedure is optional. 
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Table 34: Continuity cliecl< response procedure 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Continuity 
check response 


MGCF 


Context/Context 
Request 


M 


This information element indicates the 
existing context or requests a new context 
for the bearer termination. 






TDIVI Termination 


M 


This information element indicates the 
existing bearer termination 






Request for loop back 
of the continuity tone 


M 


This information request the IM-MGW to 
loop back the continuity check tone on the 
indicated TDIVI termination 



9.3.2.12 

This procedure is 
related resources. 



Release TDM termination 

used by the MGCF to release a TDM termination at the IM-MGW towards the PSTN and free all 



Table 35: Release TDIVI termination procedure 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Release TDIVI 
Termination 


MGCF 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Bearer Termination 


M 


This information element indicates the bearer 
termination to be released. 


Release TDM 
Termination Ack 


IM-MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 



9.3.2.13 



Termination Out-of-Service 



This procedure is used by the IM-MGW to indicate towards the MGCF that one or several physical termination(s) will 
go out of service. This procedure is the same as Termination Out-of-Service in 3GPP TS 23.205 [27]. 



9.3.2.14 



Termination heartbeat indication 



This procedure is used to report indication of hanging termination. 

Table 35a: Procedures between (G)I\/!SC server and IVIGW: IHanging termination indication 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Termination 
heartbeat 
indication 


MGW 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Bearer Termination 


M 


This information element indicates the 
bearer termination for which the 
termination heartbeat is reported. 


Termination heartbeat 


M 


Hanging termination event, as defined in 
3GPPTS 29.332 [15]. 


Termination 

heartbeat 

indication Ack 


(G)MSC-S 


Context 


M 


This information element indicates the 
context where the command was 
executed. 
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9.3.2.15 



Bearer Released 



This procedure is used by the IM-MGW to indicate towards the MGCF that an error occurred on a physical termination 
which requires the release of the termination. This procedure is the same as Bearer Released in 3GPP TS 23.205 [27]. 

9.3.2.1 6 TDM tone completed 

This procedure is used by the IM-MGW to MGCF to indicate that a tone has finished being generated at a TDM 
termination. 

This procedure is the same as Tone Completed in 3GPP TS 23.205 [27]. 

9.3.3 Procedures related to a termination towards a BICC network 

The call related procedures detailed in table 36 shall be supported. Those procedures are defined in 3GPP TS 29.332 
[15]. 

Table 36: Required procedures defined in 3GPP TS 29.332 



Procedure defined in 3GPP TS 29.332 


Remarks 


Establish Bearer 




Prepare Bearer 




Change Through-Connection 




Release Bearer 




Release Termination 




Bearer Established 




Bearer Released 




Send Tone 




Stop Tone 




Tone completed 




Play Announcement 


Optional 


Stop Announcement 


Optional 


Announcement Completed 


Optional 


Confirm Char 


Optional 


IVIodify Bearer Characteristics 


Optional 


Reserve Char 


Optional 


Bearer Modified 


Optional 


Activate Voice Processing Function 


Optional 


Tunnel Information Down 


Conditional: For IP Transport at BICC termination 


Tunnel Information Up 


Conditional: For IP Transport at BICC termination 


Termination Out-of-Service 




Termination heartbeat indication 





9.3.4 Non-call related procedures 



The procedures from 3GPP TS 23.205 [27] detailed in table 37 shall be applied for the IM-MGW handling component 
of the Mn interface. 
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Table 37: Non-call related procedures 



Procedure defined in 
3GPPTS 29.332 [15] 


Corresponding Procedure defined 
in 3GPP TS 23.205 [27] 


Remarks 


IM-MGW Out of service 


MGW Out of Service 




IM-MGW Communication Up 


MGW Communication Up 




IIVI-IVIGW Restoration 


MGW Restoration 




IIVI-IVIGW Register 


MGW Register 




IIVI-IVIGW Re-register 


MGW Re-register 




IVIGGF Ordered Re-register 


(G)MSC Server Ordered Re-register 




IVIGCF Restoration 


(G)MSC Server Restoration 




IVIGGF Out of Service 


(G)MSC Server Out of Service 




Termination Out-of-Service 


Termination Out-of-Service 


The "Termination Out-of-Service 
procedure" is used as call-related 
H.248 command as well 


Termination Restoration 


Termination Restoration 




Audit Value 


Audit Value 




Audit Capability 


Audit Capability 




Command Rejected 


Command Rejected 


The "Command Rejected" procedure 
may be used in response both to 
call-related and non-call-related 
H.248 Commands. 


IM-MGW Capability Change 


Capability Update 




IM-MGW Resource Congestion 
Handling - Activate 


MGW Resource Congestion 
Handling - Activate 




IM-MGW Resource Congestion 
Handling - Indication 


MGW Resource Congestion 
Handling - Indication 




Control association monitoring 


Control association monitoring 




Inactivity timeout activation 


Inactivity timeout activation 




Inactivity timeout indication 


Inactivity timeout indication 




Hanging termination detection 


Hanging termination detection 




Hanging termination detection 


Hanging termination detection 





9.3.5 Multiple IP Realms 

The procedures to support multiple IP realms in the present subclause are optional. 
Figure 9.3.5.1 shows a scenario where multiple IP realms are applied. 




IM-MGW 



Termination 
1 



Termination 

2 




Figure 9.3.5.1 Multiple IP realms scenario 

Shown in figure 9.3.5, the IM CNl and CS CNl represent separate IP realms. The definition of IP realm is specified in 
IETF RFC 2663 [90]. 

The termination 1 and termination2 are connected with different IP realms in the IM-MGW separately. 
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For establishing session when multiple IP realms are used in the IM-MGW, the MGCF may indicate the IP realm 
identifier to the IM-MGW. The IM-MGW shall assign the IP termination with the indicated IP realm. 

A default IP realm may be configured in IM-MGW such that if the IM-MGW has not received the IP realm identifier 
and the IM-MGW supports multiple IP realms then the default IP realm shall be used. 

If the IM-MGW does not support the option to indicate an IP realm then it is free to select any IP port. 
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Annex A: 
Void 
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Annex B (normative): 

Codec Negotiation between a BICC CS network and the IM 

CN subsystem 

B.1 Introduction 

This annex describes optional procedures for interworking of codec negotiation between a BICC CS network and the 
IM CN subsystem. 

B.2 Control plane interworking 

The following optional procedures apply in addition to the procedures of subclause 7.3 when both the BICC CS 
network and the IM CN subsystem support codec negotiation. All five variations of the bearer set-up procedures 
defined in subclauses 7.4 and 7.5 of ITU-T Q. 1902.4 [30] are supported. The codec negotiation procedures are also 
independent of the procedures for interworking between continuity procedures and SDP preconditions. 

B.2.1 Incoming call interworking from SIP to BICC at l-MGCF 
B. 2.1.1 Sending of lAM 

When the I-MGCF receives an INVITE with SDP offer, the I-MGCF shall follow the procedures of subclause B.2.5 to 
convert the list of codecs in the SDP offer into a Supported Codec List for transmission in the outgoing lAM, according 
to subclause 8.3.1 of ITU-T Q. 1902.4 [30], and deleting those codecs not supported at the IM-MGW. When generating 
the Supported Codec List, the I-MGCF should add to the SDP offer all codec configurations for which it can provide 
transcoding. The I-MGCF shall allocate any IM-MGW resources as necessary to support the chosen bearer set-up 
procedures towards the BICC CS network. 

When the I-MGCF receives an INVITE without SDP offer, the I-MGCF shall continue call establishment without 
interworking of codec negotiation procedures. The mid-call interworking procedures of subclause B.2. 3 and subclause 
B.2.4 may still apply. 

B.2.1 .2 Sending of SDP answer 

The I-MGCF shall suspend the SDP answer procedure until it receives backward codec information from the BICC 
serving node terminating codec negotiation. When the I-MGCF receives the backward codec information, it shall select 
a codec configuration for use on the bearer interface to the IM CN subsystem from the codecs in the SDP offer, format 
an SDP answer based on this selected codec, send the SDP answer to the offerer in the appropriate SIP message (e.g., a 
reliable 18x response), and complete bearer establishment procedures. To avoid allocating a transcoder at the IM- 
MGW, the I-MGCF should preferably select a codec for the IM CN subsystem by converting the Selected Codec from 
the BICC CS network into an SDP answer according to the procedures of subclause B.2.5, if allowed by the SDP 
offer/answer rules. Otherwise the I-MGCF should select the highest priority codec from the codecs in the received SDP 
offer supported by the IM-MGW for insertion in the SDP answer. Note that the I-MGCF stores the Available Codec 
List and does not send it to the offerer in the SDP answer. Codec negotiation is complete so it is not necessary for the 
offerer to begin a second phase offer/answer exchange using the PRACK request. 

B.2.2 Outgoing call interworking from BICC to SIP at 0-MGCF 



B.2.2.1 Sending of INVITE 



When the O-MGCF receives an lAM, the O-MGCF shall follow the procedures of subclause B.2.5 to convert the 
Supported Codec List from the lAM into an SDP offer for transmission in the outgoing INVITE request, according to 
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RFC 3264, deleting those codecs not supported at the IM-MGW. When generating the SDP offer, the O-MGCF should 
include all codec configurations for which it can provide transcoding in addition to those converted from the Supported 
Codec List. The O-MGCF shall include at least one AMR codec configuration in the SDP offer. The O-MGCF shall 
allocate any IM-MGW resources as necessary to support the inclusion of session address information in the SDP offer 
towards the IM CN subsystem. 

B.2.2.2 Responding to serving node initiating codec negotiation 

The O-MGCF shall suspend the incoming bearer set-up procedure while waiting for receipt of the SDP answer from the 
IM CN subsystem. When the O-MGCF receives the SDP answer while suspending the incoming bearer set-up 
procedure, it shall select a codec configuration for use on the bearer interface to the IM CN subsystem from the codecs 
in the SDP answer, construct the Available Codec List for the BICC CS network from the list of codecs received in the 
Supported Codec List by removing codecs not supported at the IM-MGW, choose the Selected Codec for the BICC CS 
network from the codecs in the Available Codec List, initiate the second SDP offer/answer exchange with the IM CN 
subsystem using the codec selected for the IM CN subsystem, if necessary, and resume the incoming bearer set-up 
procedure in the BICC CS network. The O-MGCF should select codecs for the bearer interfaces to the BICC CS 
network and IM CN subsystem in such a way as to avoid transcoding at the IM-MGW and minimize speech 
degradation, if possible, according to subclause B.2.5. Otherwise the O-MGCF should choose the highest priority codec 
from the Available Codec List as the Selected Codec for the BICC CS network, and the highest priority codec from the 
codecs in the SDP answer as the codec for the IM CN subsystem. If the SDP answer only included a single voice codec, 
then there is no need for a second SDP offer/answer exchange, and the codec selected for the IM CN subsystem is the 
codec in the SDP answer. 

Certain BICC timers or events can force completion of the incoming bearer set-up procedure before the O-MGCF 
receives the SDP answer from the IM CN subsystem. In this case, the O-MGCF shall perform the terminating codec 
negotiation procedure according to subclause 8.3.3 of ITU-T Q. 1902.4 [30], including all supported codecs in the 
Available Codec List, and shall resume the incoming bearer set-up procedure without waiting any longer for the SDP 
answer. 

When an SDP answer arrives from the IM CN subsystem in response to the SDP offer in an INVITE request after the 
BICC incoming bearer set-up procedure has started, the O-MGCF shall select a codec configuration for use on the 
bearer interface to the IM CN subsystem from the codecs in the SDP answer, choose a new Selected Codec for the 
BICC CS network from the codecs in the Available Codec List constructed during incoming bearer set-up, and initiate 
the second SDP offer/answer exchange with the IM CN subsystem using the codec selected for the IM CN subsystem, if 
necessary. The O-MGCF should select codecs for the bearer interfaces to the BICC CS network and IM CN subsystem 
in such a way as to avoid transcoding at the IM-MGW and minimize speech degradation, if possible, according to 
subclause B.2.5. Otherwise the O-MGCF should select the highest priority codecs from the available options for the two 
bearer interfaces. If the SDP answer only included a single voice codec, then there is no need for a second SDP 
offer/answer exchange, and the codec selected for the IM CN subsystem is the codec in the SDP answer. When the call 
in the BICC CS network enters a state capable of supporting codec modification, if the new Selected Codec is different 
from the Selected Codec chosen during the incoming bearer set-up procedure for the BICC CS network, the O-MGCF 
should initiate the codec modification procedure towards the BICC CS network using the new Selected Codec, 
according to subclause 10.4.1 of ITU-T Q. 1902.4 [30]. 

B.2.3 Mid-call interworking from SIP to BICC at l-MGCF or O- 
MGCF 



B.2.3. 1 Receipt of SDP offer 



When the MGCF receives a SIP message (e.g. UPDATE request or re-INVITE request) with an SDP offer that is not 
associated with incoming call bearer establishment or preconditions, if the call is in a state capable of supporting BICC 
codec negotiation, the MGCF shall follow the procedures of subclause B.2.5 to convert the list of codecs in the SDP 
offer into a Supported Codec List, delete those codecs in the Supported Codec List not supported at the IM-MGW, and 
initiate the mid-call codec negotiation procedure according to subclause 10.4.4 of ITU-T Q. 1902.4 [30], by sending an 
APM with the Supported Codec List and an Action indicator set to "mid-call codec negotiation". When generating the 
Supported Codec List, the MGCF should add to the SDP offer all codec configurations for which it can provide 
transcoding. 

When the MGCF receives a SIP message with an SDP offer that is not associated with incoming call bearer 
establishment or preconditions, if the call is not in a state capable of supporting BICC codec negotiation, the MGCF 
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shall respond to the SDP offer with existing procedures for the IM CN subsystem. When the call is in a state capable of 
supporting BICC codec negotiation, the MGCF may send a re -INVITE request without SDP towards the IM CN 
subsystem, soliciting a response with an SDP offer, thereby restarting the codec negotiation interworking procedure. 

B. 2.3.2 Generating SDP answer 

After initiating a BICC codec negotiation procedure towards the BICC CS network in response to receipt of a SIP 
message with an SDP offer from the IM CN subsystem, the MGCF shall suspend the SDP answer procedure until it 
receives codec information from the succeeding BICC serving node. If the succeeding serving node returns a successful 
response, the MGCF shall select a codec configuration for use on the bearer interface to the IM CN subsystem from the 
codecs in the SDP offer, format an SDP answer based on this selected codec, send the SDP answer to the offerer in the 
appropriate SIP message (e.g. 200 OK (UPDATE) or 200 OK (INVITE)), send an APM to the succeeding serving node 
with an Action indicator set to "successful codec modification", and complete bearer establishment procedures. To 
avoid allocating a transcoder at the IM-MGW, the MGCF should preferably select a codec for the IM CN subsystem by 
converting the Selected Codec from the BICC CS network into an SDP answer according to the procedures of subclause 
B.2.5, if allowed by the SDP offer/answer rules. Otherwise the MGCF should select the highest priority codec from the 
codecs in the received SDP offer supported by the IM-MGW for insertion in the SDP answer. Note that the MGCF 
stores the Available Codec List and does not send it to the offerer in the SDP answer. 

If the succeeding serving node returns an Action indicator set to "mid-call codec negotiation failure", the MGCF either 
should send a 488 response to the SDP offerer indicating rejection of the initial SDP offer, or should select the highest 
priority codec from the codecs in the received SDP offer supported by the IM-MGW, format an SDP answer based on 
this selected codec, and send the SDP answer to the offerer in the appropriate SIP message. If the MGCF sends a 488 
response to the SDP offerer, it should continue the call with the bearer configuration in place before initiating this codec 
negotiation procedure. 

B.2.4 Mid-call interworking from BICC to SIP at l-MGCF or O- 
MGCF 

B.2.4. 1 Receipt of mid-call codec negotiation request 

When the MGCF receives an APM with an Action indicator set to "mid-call codec negotiation", the MGCF shall follow 
the procedures of subclause B.2.5 to convert the Supported Codec List from the APM into an SDP offer for 
transmission in an appropriate SIP message (e.g. re-INVITE request) towards the IM CN subsystem, according to RFC 
3264 [36], deleting those codecs not supported at the IM-MGW. When generating the SDP offer, the MGCF should 
include all codec configurations for which it can provide transcoding in addition to those converted from the Supported 
Codec List. The MGCF shall include at least one AMR codec configuration in the SDP offer. 

B.2.4. 2 Responding to serving node initiating mid-call codec negotiation 

The MGCF shall delay responding to the mid-call codec negotiation from the BICC CS network until it receives a 
response to the SDP offer from the IM CN subsystem. If the MGCF receives an SDP answer, it shall construct the 
Available Codec List for the BICC CS network from the list of codecs received in the Supported Codec List by 
removing codecs not supported at the IM-MGW, choose the Selected Codec for the BICC CS network from the codecs 
in the Available Codec List, and complete the mid-call codec negotiation procedure towards the preceding serving node 
according to subclause 10.4.5 of ITU-T Q. 1902.4 [30]. The MGCF should choose the Selected Codec for the BICC CS 
network in such a way as to avoid transcoding at the IM-MGW and minimize speech degradation, if possible, according 
to subclause B.2.5. Otherwise the MGCF should choose the highest priority codec from the Available Codec List for the 
Selected Codec for the BICC CS network. If the MGCF receives an APM from the preceding serving node with an 
Action indicator set to "codec modification failure", then the MGCF may initiate a new SDP offer/answer exchange 
towards the IM CN subsystem in an attempt to recreate the bearer configuration in place before this codec negotiation 
procedure began. 

If the MGCF receives a 488 response or other failure response (e.g. 3xx-6xx) to the SDP offer, either it should reject the 
mid-call codec negotiation from the BICC CS network by sending an APM with an Action indicator set to "mid-call 
codec negotiation failure" towards the preceding serving node, or it should continue as if it received an SDP answer 
with no change in codec selected for the IM CN subsystem. If the MGCF sends an APM with an Action indicator set to 
"mid-call codec negotiation failure", it should continue the call with the bearer configuration in place before initiating 
this codec negotiation procedure. 



£75/ 



3GPP TS 29.1 63 version 9.1 3.0 Release 9 222 ETSI TS 1 29 1 63 V9.1 3.0 (201 3-04) 

B.2.4.3 Receipt of codec modification request 

If the MGCF receives an APM from a BICC CS network that includes an Action indicator set to "modify codec" with 
no change in the selected codec, it shall act as a serving node terminating codec modification, according to subclause 
10.4.2 of ITU-T Q. 1902.4 [30], without interworking the procedure with the IM CN subsystem. 

If the MGCF receives an APM from a BICC CS network that includes an Action indicator set to "modify codec" and 
the new selected codec in the message is different from the Selected Codec at the IM-MGW bearer interface to the 
BICC CS network, the MGCF either may act as a serving node terminating codec modification, according to subclause 
10.4.2 of ITU-T Q. 1902.4 [30], without interworking the procedure with the IM CN subsystem, or may follow the 
procedures of subclause B.2.5 to convert the new Available Codec List (with new priority order) from the APM into an 
SDP offer for transmission in an appropriate SIP message (e.g. re-INVITE request) towards the IM CN subsystem, 
according to RFC 3264 [36], deleting those codecs not supported at the IM-MGW. When generating the SDP offer, the 
MGCF should include all codec configurations for which it can provide transcoding in addition to those converted from 
the new Available Codec List. The MGCF shall include at least one AMR codec configuration in the SDP offer. 

If the MGCF sends a SIP message with an SDP offer towards the IM CN subsystem in response to receipt of a BICC 
codec modification request, then it shall delay responding to the BICC codec modification request until it receives a 
response to the SDP offer from the IM CN subsystem. When the MGCF receives either an SDP answer or a rejection of 
the SDP offer within the appropriate SIP message (e.g. 200 OK (INVITE)) from the IM CN subsystem, it shall decide 
whether to accept or reject the BICC codec modification procedure and complete the procedure for a BICC serving 
node terminating codec modification, according to subclause 10.4.2 of ITU-T Q. 1902.4 [30]. 

If the MGCF sends an APM with an Action indicator set to "codec modification failure" in response to receipt of a 
codec modification request, the preceding BICC serving node may retry the request with a mid-call codec negotiation 
using an APM including an Action indicator set to "mid-call negotiation" and a Supported Codec List with a new 
priority order encouraging selection of a new codec. 

B.2.5 Codec parameter translation between BICC CS network 
and the IM CN subsystem 

The IM CN subsystem uses the Session Description Protocol (SDP, defined in IETF RFC 4566 [56]) to select and 
potentially re-negotiate the codec type and configuration and associated bearer format attributes to be used in the user 
plane. IETF RFC 3550 [51] defines the Real Time Protocol (RTP) for framing of all codecs in the user plane, IETF 
RFC 3551 [52] and IETF RFC 3555 [53] define the framing details for many of the ITU-T codecs, and IETF 
RFC 4867 [23] defines framing details for the AMR family of codecs. This subclause will focus only on codec-specific 
SDP parameters not already constrained by subclause 5.1.1 of 3GPP TS 26.236 [32] . The signalling plane of the IM CN 
subsystem uses SDP offer/answer procedures defined in IETF RFC 3264 [36] to select the desired codec type and 
configuration for the user plane from a prioritized list of codec types and configurations and to re -negotiate the user 
plane attributes as necessary. 

The bearer independent CS network uses the Single Codec and Codec List information elements of the Application 
Transport Mechanism (APM) defined in ITU-T Recommendation Q.765.5 [35] to negotiate (offer and select) and 
potentially re-negotiate the codec type and configuration and associated bearer format attributes to be used in the user 
plane. 3GPP TS 29.414 [25] and 3GPP TS 29.415 [26] define the luFP framing protocol for all codecs in the user plane 
for both ATM and IP transport, and 3GPP TS 26.102 [50] provides the framing details for AMR and PCM family 
codecs. The Codec List information element of the APM comprises multiple instances of the Single Codec information 
element in priority order, as shown in figure 13 of ITU-T Recommendation Q.765.5 [35]. Figure 14 of ITU-T 
Recommendation Q.765.5 [35] defines the Single Codec information element. Subclause 11.1.7.2 of ITU-T 
Recommendation Q.765.5 [35] defines the encoding of the Single Codec information element for the ITU-T codecs. 
3GPP TS 26.103 [57] defines the encoding of the Single Codec information element for the 3GPP codecs, and table 
7.11.3.1.3-2 of 3GPPTS 28.062 [58] defines the preferred configurations of the narrowband AMR codecs (Config-NB- 
Code) for interoperation with TFO. The signalling plane of the bearer independent CS network uses the APM to 
negotiate the desired codec type and configuration for the user plane from the prioritized list of codec types and to re- 
negotiate the user plane attributes as necessary. 

The following subclauses define the translations between the SDP payload format parameters of the IM CN subsystem 
and the corresponding subfields of the Single Codec information element of the bearer independent CS network for 
certain 3GPP and ITU-T codecs. Following these translation rules will in many cases allow the IM-MGW to perform 
interworking between the framing protocols on the bearer interfaces to the BICC CS network and the IM CN subsystem 
without transcoding. Implementations may signal other codec types not listed herein or other codec configurations of 
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codec types listed herein. Implementations may also choose to perform transcoding between codec configurations 
signalled separately for the bearer interfaces to the networks, if necessary, but voice quality may suffer. 

B.2.5.1 Codec parameters for 3GPP AMR-NB codecs 

Table B.l shows the correspondence between the codec format parameters in the Single Codec information element 
(3GPP TS 26.103 [57]) and the SDP for the 3GPP narrowband AMR codecs (IETF RFC 4867 [23]). 

Table B.1 : Mapping between Single Codec subfields and SDP parameters for 3GPP AMR-NB codecs 



Single Codec information element 


SDP payload format parameters | 


Codec 
IDentification 


ACS, SCS, OM, MACS 


Payload 

Type 
number 


Encoding 
name 


Other Parameters 

(NOTE 1) (NOTE 2) 


FR AMR or 
OHR AMR or 
HR AMR 


OM=0 or 

Selected Codec Type 


dynamic 


AMR 


mode-set=values corresponding 
to ACS (NOTE 3) 


FR AMR or 
OHR AMR or 
HR_AMR 


(0M=1 or OM not present) and 
(Supported Codec List or Available 
Codec List) 


dynamic 


AMR 


mode-set=select from values 
corresponding to ACS, SCS and 
MACS (NOTE 3) 


UMTS_AMR 


OM=0 or 

Selected Codec Type 


dynamic 


AMR 


mode-set=values corresponding 
to ACS 


UMTS_AMR 


(0M=1 or OM not present) and 
(Supported Codec List or Available 
Codec List) 


dynamic 


AMR 


mode-set=select from values 
corresponding to ACS, SCS and 
MACS (NOTE 4) 


UMTS_AMR_2 


OM=0 or 

Selected Codec Type 


dynamic 


AMR 


mode-set=values corresponding 
to ACS (NOTE 5) 


UMTS_AMR_2 


(0M=1 or OM not present) and 
(Supported Codec List or Available 
Codec List) 


dynamic 


AMR 


mode-set=select from values 
corresponding to ACS, SCS and 
MACS (NOTE 3) (NOTE 5) 


NOTE 1 : Table 1 of IETF RFC 4867 [23] provides the correspondence between codec rates and AMR modes for use 
when generating the "mode-set" parameter. When all modes are selected for use, the "mode-set" 
parameter shall not be included in SDP. 

NOTE 2: SDP payload format configurations in this table with only one value in the "mode-set" parameter shall not 
include the "mode-change-period" and "mode-change-neighbor" parameters. 

NOTE 3: Payload types for FR_AMR, OHR_AMR and HR_AMR with more than one value in the "mode-set" 

parameter shall include the "mode-change-period=2" and "mode-change-capability=2" parameters and 
should include the" mode-change-neighbor=1" parameter. 

NOTE 4: IETF RFC 4867 [23] does not currently provide a mechanism to signal the SCS, MACS or OM parameters 
in SDP, nor does it distinguish between the different AMR-NB codec types. Each AMR-NB codec type in 
the Supported Codec List or the Available Codec List with 0M=1 should be translated into a list of SDP 
payload formats in priority order, where each includes a "mode-set" parameter with a unique value derived 
from the ACS, SCS and MACS. Each "mode-set" should correspond to a codec configuration that is 
compatible with the given codec type according to the compatibility rules defined in clauses 1 1 and 12 of 
3GPP TS 28.062 [58]. 

NOTE 5: Payload types for UMTS_AMR_2 should include the "mode-change-period=2", "mode-change-capability=2" 
and "mode-change-neighbor=1" parameters, normally used for signalling GSM AMR codecs, to assure end- 
to-end interoperability with OoBTC and TFO. Its actual capabilities would otherwise be signalled without 
these parameters. 



Definitions: 

Supported Codec List: contains the offered Codec Types and Configuration-possibilities of the node initiating codec 
negotiation in BICC (see also 3GPP TS 23.153). The Supported Codec List is sent from the initiating node forward to 
the terminating node. The Supported Codec List corresponds to an SDP offer during codec negotiation. 

Available Codec List: contains the offered Codec Types and Configuration-possibilities of the contiguous portion of 
the connection between initiating and terminating BICC nodes, including all intermediate nodes through the BICC 
network(s). The Available Codec List is sent from the BICC node terminating codec negotiation backward to the 
initiating node. The Available Codec List corresponds to information sometimes available in a first-round SDP answer. 
The Available Codec List might not represent an end-to-end view of the available Codec Types and Configuration- 
possibilities when traversing both BICC and SIP networks. 
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Selected Codec Type: is determined by the node terminating codec negotiation. It specifies exactly the Codec Type and 
one unique Codec Configuration for the call. The Selected Codec Type corresponds to the final SDP answer. 

When translating from a Single Codec information element to the equivalent SDP payload format parameters, where 
either OM=0 (in the Supported or Available Codec List) or the information element is the Selected Codec Type, the 
SDP shall include a single payload type and any associated parameters from the corresponding row in table B.l. When 
translating from a Single Codec information element to the equivalent SDP payload format parameters, where OM=l in 
the Supported or Available Codec List, the SDP shall only include payload formats corresponding to Codec 
Configurations compatible with the offered ACS, SCS and MACS, according to table B.l. Since the number of 
compatible payload formats can be large, implementations should select a reasonable subset of the higher-priority 
payload formats for inclusion in the SDP. When translating a list of Single Codec information elements into SDP, 
duplicate payload types (matching on all parameters) shall be removed. 

The following guidelines shall apply when translating from an SDP payload format specification to a Single Codec 
information element; 

If there is no "mode-set" parameter for a payload format in the SDP and the SDP is to be translated into a 
Supported or Available Codec List, then the corresponding Single Codec subfields shall be OM=l, MACS=8, all 
SCS modes offered, and ACS modes offered. Alternatively it is sufficient to specify only the Codec Type (see 
below) and omit the other parameters. 

If there is no "mode-set" parameter for a payload format in an SDP answer that is to be translated into a Selected 
Codec Type, then the corresponding Single Codec subfields shall be derived from the payload type in the SDP 
offer (to which the SDP answer was sent in response). 

If there is a "mode-set" parameter for a payload format in the SDP, then the corresponding Single Codec 
subfields shall be OM=0 and ACS modes selected according to the value of "mode-set". The SCS shall be set 
identical to the ACS and MACS shall be set to the number of modes in the ACS. If this "mode-set" does not 
represent a valid configuration for the Codec Type (determined by OoBTC procedures), then the payload format 
shall not be translated. 

If a payload format in an SDP offer that is to be translated into a Supported Codec List includes "mode-change- 
period=2" parameter or includes "mode -change -capability=2" parameter, then the Codec IDentification value for 
the corresponding Single Codec shall be FR_AMR. 

If a payload format in an SDP answer that is to be translated into a Selected Codec Type or Available Codec List 
includes "mode-change -period=2", then the Codec IDentification value for the corresponding Single Codec shall 
be one of FR_AMR, HR_AMR, OHR_AMR or UMTS_AMR_2, if offered in the Supported Codec List. 

If a payload format in an SDP offer that is to be translated into a Supported Codec List does not include "mode- 
change -period=2" parameter and does not include "mode-change-capability=2" parameter, then the Codec 
IDentification value for the corresponding Single Codec shall be UMTS_AMR. 

If a payload format in an SDP answer that is to be translated into a Selected Codec Type or Available Codec List 
does not include "mode-change-period=2" parameter and does not include "mode-change-capability=2" 
parameter, then the Codec IDentification value for the corresponding Single Codec shall be one of 
UMTS_AMR_2, FR_AMR, HR_AMR, OHR_AMR or UMTS_AMR, if offered in the Supported Codec List. 

B. 2.5.2 Codec parameters for 3GPP AMR-WB codecs 

Table B.2 shows the correspondence between the codec format parameters in the Single Codec information element 
(3GPP TS 26.103 [57]) and the SDP for the 3GPP wideband AMR codecs (IETF RFC 4867 [23]). 
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Table B.2: Mapping between Single Codec subfields and SDP parameters for 3GPP AMR-WB codecs 



Single Codec information element 


SDP payload format parameters | 


Codec IDentification 


Config-WB-Code 


Payload Type number 


Encoding name 


Other Parameters 

(N0TE1) 


FR AMR-WB or 
OHR AMR-WB 





dynamic 


AMR-WB 


mode-set=0,1,2 


OFR AMR-WB or 
UMTS AMR-WB 





dynamic 


AMR-WB 


mode-set=0,1,2 
(NOTE 2) 


OFR AMR-WB or 
UMTS_AMR-WB 


1 


dynamic 
dynamic 
dynamic 


AMR-WB 
AMR-WB 
AMR-WB 


mode-set=0,1,2 
mode-set=0,1,2,8 
mode-set=0, 1,2,4 
(NOTE 2) 


OFR AMR-WB or 
UMTS AMR-WB 


2 


dynamic 


AMR-WB 


mode-set=0, 1,2,4 
(NOTE 2) 


OFR AMR-WB or 
UMTS_AMR-WB 


3 


dynamic 
dynamic 
dynamic 


AMR-WB 
AMR-WB 
AMR-WB 


mode-set=0,1,2,4 
mode-set=0,1,2,8 
mode-set=0,1,2 
(NOTE 2) 


OFR AMR-WB or 
UMTS AMR-WB 


4 


dynamic 


AMR-WB 


mode-set=0,1,2,8 
(NOTE 2) 


OFR AMR-WB or 
UMTS_AMR-WB 


5 


dynamic 
dynamic 
dynamic 


AMR-WB 
AMR-WB 
AMR-WB 


mode-set=0,1,2,8 
mode-set=0,1,2,4 
mode-set=0,1,2 
(NOTE 2) 


NOTE 1 : Payload types for FR_AMR-WB, OHR_AMR-WB and OFR_AMR-WB shall include the "mode-change- 

period=2" and "mode-change-capability=2" parameters and should include the " mode-change-neighbor=1" 
parameter. 

NOTE 2: Payload types for UMTS_AMR-WB should include the "mode-change-period=2", "mode-change- 

capability=2" and "mode-change-neighbor=1" parameters, normally used for signalling GSM AMR-WB 
codecs, to assure end-to-end interoperability with OoBTC and TFO. Its actual capabilities would otherwise 
be signalled without these parameters. 



When translating from a Single Codec information element to the equivalent SDP payload format parameters, the SDP 
shall include a distinct payload type and any associated parameters for each row in the table that matches the Config- 
WB-Code parameter. For example, OFR_AMR-WB with Config-WB-Code=3 can generate three SDP payload types 
for AMR-WB, each including the "mode-change-period=2" parameter, the "mode-change-neighbor=l" parameter, and 
the "mode-set" parameter with value sets "0,1,2,4", "0,1,2,8", and "0,1,2", respectively. When translating a list of Single 
Codec information elements into SDP, duplicate payload types (matching on all parameters) shall be removed. 

The following guidelines shall apply when translating from one or more SDP payload format specifications to a Single 
Codec information element: 

Payload formats that match except for different values of "mode-set" shall be represented with the fewest values 
of Config-WB-Code, while retaining the priority represented by the order of the payload formats in the SDP. For 
example, three SDP payload types for AMR-WB, each including the "mode-change -period=2" parameter, the 
"mode-change-neighbor=r' parameter, and the "mode-set" parameter with value sets "0,1,2,4", "0,1,2,8", and 
"0,1,2", respectively, will generate Config-WB-Code=3. 

If there is no "mode-set" parameter for a payload format in the SDP and the SDP is to be translated into a 
Supported or Available Codec List, then the corresponding Single Codec shall have a Config-WB-Code value of 
1. 

If there is no "mode-set" parameter for a payload format in an SDP answer that is to be translated into a Selected 
Codec Type, then the corresponding Config-WB-Code value shall be derived from the payload type in the SDP 
offer (to which the SDP answer was sent in response). 

If a payload format in an SDP offer that is to be translated into a Supported Codec List includes "mode-change- 
period=2" parameter or includes "mode -change -capability=2" parameter, then the Codec IDentification value for 
the corresponding Single Codec shall be OFR_AMR-WB. 

If a payload format in an SDP answer is to be translated into a Selected Codec Type or Available Codec List, 
then the Codec IDentification value for the corresponding Single Codec shall be one of OFR_AMR-WB, 
FR_ AMR-WB, OHR_AMR-WB or UMTS_AMR-WB, if offered in the Supported Codec List. 
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If a payload format in an SDP offer that is to be translated into a Supported Codec List does not include "mode- 
change -period=2" parameter and does not include "mode-change-capability=2" parameter, then the payload 
format shall not be translated. 

B.2.5.3 Codec parameters for 3GPP non-AMR codecs 

Table B.3 shows the correspondence between the codec format parameters in the Single Codec information element 
(3GPP TS 26.103 [57]) and the SDP for the 3GPP non-AMR codecs (IETF RFC 4867 [23], IETF RFC 3551 [52], IETF 
RFC 3555 [53] and IETF RFC 5993 [1 14]). 

Table B.3: Mapping between Single Codec subfields and SDP parameters for 3GPP non-AMR codecs 



Single Codec information element 


SDP payload format parameters | 


Codec IDentification 


Payload Type number 


Encoding name 


Other Parameters 


GSMFR 


3 


GSM 




GSMHR 


dynamic 


GSM-HR-08 




GSM EFR (NOTE 1) 


dynamic 


GSM-EFR 




GSM EFR (NOTE 2) 


dynamic 


AMR 


mode-set=7 


TDMA EFR (NOTE 2) 


dynamic 


AMR 


mode-set=4 


PDC EFR (NOTE 2) 


dynamic 


AMR 


mode-set=3 


NOTE 1 : This translation for GSM EFR (GSM-EFR) is preferred to the alternative (AMR mode-set=7) if it is 
supported by the IM-MGW. 

NOTE 2: AMR DTX is not compatible with the DTX schemes for any of the codecs in this list. The IM-MGW may 
support these configurations without transcoding by providing interworking between the DTX procedures 
and frame encodings on the bearer interfaces to the BIGG OS network and the IM CN subsystem. 



B.2.5.4 Codec parameters for ITU-T codecs 



Table B.4 shows the correspondence between the codec format parameters in the Single Codec information element 
(Subclause 11.1.7 of ITU-T Q.765.5 [35]) and the SDP for the ITU-T codecs (Table 4 of RFC 3551 [52], and RFC 3555 
[53]). 
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Table B.4: Mapping between Single Codec subfields and SDP parameters for ITU-T codecs 



Single Codec information element 


SDP payload format parameters | 


Codec Type 
subfield 


Codec Name 


Codec Configuration 
subfield (dcba) 


Payload Type 
number 


Encoding 
name 


Other 
Parameters 


00000001 


G.71 1 64 kbit/s A-law 


N/A 


8 


PCMA 




00000010 


G.71 1 64 kbit/s n-law 


N/A 





PCMU 




00000011 


G.71 1 56 kbit/s A-law 


N/A 


N/A 


N/A 




00000100 


G.71 1 56 kbit/s ^i-law 


N/A 


N/A 


N/A 




00000101 


G.722 (SB-ADPCM) 


N/A 


9 


G722 




00000110 


G.723.1 


N/A 


4 


G723 


annexa=no 


00000111 


G.723.1 Annex A 
(silence suppression) 


N/A 


4 


G723 




00001000 


G.726 (ADPCM) 


xxx1 
xxlx 
xlxx 
Ixxx 


dynamic 
dynamic 
dynamic 
dynamic 


G726-16 
G726-24 
G726-32 
G726-40 




00001001 


G.727 (Embedded 
ADPCM) 


xxxx 


N/A 


N/A 




00001010 


G.728 


111 

(subsets of defined 

rates not supported) 


15 


G728 




00001011 


G.729 (CS-ACELP) 


XX 1 

xlx 
Ixx 


dynamic 

18 

dynamic 


G729D 

G729 

G729E 


annexb=no 
annexb=no 
annexb=no 


00001100 


G.729 Annex B 
(silence suppression) 


xxl 
xlx 
Ixx 


dynamic 

18 

dynamic 


G729D 

G729 

G72"E" 


NOTE: An "x" in a bit position of the Codec Configuration subfield indicates a "don't care" value. The SDP 
payload description for each listed codec includes a clock rate of 8000 Hz. TS 26.102 [50] only 
describes the BICC CS network framing for the PCIVI codecs. 



When translating from a Single Codec information element to the equivalent SDP payload format parameters, the SDP 
shall include a distinct payload type and any associated parameters for each matching instance of the Codec 
Configuration subfield. For example, G.726 (ADPCM) with Codec Configuration subfield "0101" shall generate SDP 
payload types for G726-32 and G726-16. 

When translating from an SDP payload format specification to the Single Codec information element, each SDP 
payload type should be represented by one matching Single Codec information element. For example, SDP payload 
types for G729 and G729E may generate one Single Codec information element for "G.729 Annex B" with Codec 
Configuration subfield "110". The G729 and G729E codecs may alternately be represented by two Single Codec 
information elements for "G.729 Annex B" with Codec Configuration subfields "100" and "010", respectively, if it is 
necessary to indicate preference between them. 



B.3 MGCF - IM-MGW interaction during interworking of 
codec negotiation 

B.3.1 Basic IIVI CN subsystem originated session 

This subclause shows an example of the interworking of codec negotiation between an IM CN subsystem and a BICC 
CS network during session establishment for an IM CN subsystem originated session. The example applies to BICC 
forward bearer establishment. Similar procedures apply to the other four versions of bearer establishment procedure 
applicable to the BICC CS network. The exchange of codec information is identical in all five cases, but there are 
differences in the sequence of operations associated with bearer establishment within the BICC CS network. 
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B.3.1 .1 BICC forward bearer establishment 

B.3.1.1.1 IM-MGW selection 

The MGCF shall select an IM-MGW for the bearer connection before it performs the CS network side bearer 
establishment. This may happen either before sending the lAM or after receiving the APM message (signal 3 or signal 4 
in figure B.l). In the latter case, the IM-MGW selection may be based on a possibly received MGW-id from the 
succeeding node. 

B.3.1 .1 .2 CS network side bearer establishment 

The MGCF shall either select bearer characteristics or request the IM-MGW to select and provide the bearer 
characteristics for the CS network side bearer connection before sending the lAM. In the latter case the MGCF shall use 
the Prepare Bearer procedure, not shown in figure B.l, to request the IM-MGW to select the bearer characteristics. 
After the succeeding node has provided a bearer address and a binding reference in the APM, the MGCF shall use the 
Establish Bearer procedure to request the IM-MGW to establish a bearer towards the destination CS-MGW. The MGCF 
shall provide the IM-MGW with the bearer address, the binding reference and the bearer characteristics (signal 5 in 
figure B.l). 

B.3.1 .1 .3 IM CN subsystem side session establishment 

When the MGCF receives the Selected Codec from the succeeding serving node in the CS network (signal 4 in figure 
B.l) and selects a codec for use in the IM CN subsystem, the MGCF shall initiate the Reserve IMS Connection Point 
and Configure Remote Resources procedure (signal 7 and 8 in figure B.l). From the received SDP and selected 
configuration data the MGCF: 

Shall send the appropriate remote codec(s), the remote UDP port and the remote IP address to the IM-MGW. 
The remote UDP port and IP address refer to the destination of user plane data sent towards the IM CN 
subsystem. The remote codec(s) are the codec(s) the IM-MGW may select for user plane data sent towards the 
IM CN subsystem. 

Shall indicate to the IM-MGW the appropriate local codec(s) and request a local IP address and UDP port. The 
local IP address and UDP port are used by the IM-MGW to receive user plane data from the IM CN subsystem. 
The local codec(s) are the codec(s) the IM-MGW may select to receive user plane data from the IM CN 

subsystem. 

If DTMF support together with speech support is required, the reserve value indicator shall be set to "true". 

The IM-MGW 

Shall reply to the MGCF with the selected local codec(s) and the selected remote codec(s) and the selected local 
UDP port and IP address. 

Shall reserve resources for those codec(s). 

The MCGF shall send the local codec(s), UDP port and IP address to the IMS in the Session Progress (signal 9 in figure 
B.l). 

B.3.1. 1.4 Through-connection 

During the Prepare Bearer and Establish Bearer procedures, the MGCF shall either use the Change Through-Connection 
procedure to request the IM-MGW to backward through-connect the BICC terminations, or the MGCF shall use this 
procedure to both-way through-connect the BICC termination already on this stage (signal 5 in figure B.l). During the 
Reserve IMS Connection Point procedure, the MGCF shall use the Change IMS Through-Connection procedure to 
request the IM-MGW to backward through-connect the IMS termination (signal 7 in figure B.l). 

When the MGCF receives the BICCiANM answer indication, it shall request the IM-MGW to both-way through- 
connect the termination using the Change Through-Connection or Change IMS Through-Connection procedures (signal 
20 in figure B.l), unless those terminations are already both-way through-connected. 
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B.3.1.1.5 Codec handling 

The IM-MGW may include a speech transcoder based upon the speech coding information provided to each 
termination. 

B.3.1 .1 .6 Failure handling in MGCF 

If any procedure between the MGCF and the IM-MGW is not completed successfully the default action by the MGCF is 
to release the session, as described in subclause 9.2.6. If the MGCF receives a Bearer Released procedure from the IM- 
MGW the default action by the MGCF is to release the session as described in subclause 9.2.7. 

NOTE; As an implementation option the MGCF may also decide for example to only release the resources in the 
IM-MGW that caused the failure, possibly select a new IM-MGW for the connection and continue the 
call establishment using new resources in the selected IM-MGW but such handling is outside of the scope 
of the present document. 

B.3.1 .1 .7 Message sequence chart 

Figure B.l shows the message sequence chart for the IM CN subsystem originating session with BICC forward bearer 
establishment where the selection of IM-MGW is done after receipt of the APM. The MGCF then requests the seizure 
of a CS network side bearer termination and the establishment of the bearer. When the MGCF receives an answer 
indication, it requests the IM-MGW to both-way through-connect the terminations. 
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1. SIP: INVITE 
[supported codec list 1] 



2. SIP : 100 Trying 



Establisin Bearer, Cinange 
Tinrough-Connection = both 



Reserve IMS Connection Point 
and Configure Remote 
Resources, Change IMS 
Through-Connection = backward 



9. SIP :1 83 [selected codec 1 ] 

10. SIP: PRACK 
1 

11.S1P :200 OK (PRACK) 

12. SIP: UPDATE 
13.S1P :200 OK (UPDATE) 



16. SIP :180 Ringing 

17. SIP: PRACK 
18.S1P :200 OK (PRACK) 



22. SJP :200 OK (INVITE) 



23. SIP: ACK 



3. BICC : lAM [supported codec list 2] 



4. BICC : APM [selected codec 2] 



5. H.248 : ADD.req [Context ID = ?, Termination ID = ?] 



6. H.248 : ADD.resp [Context ID = CI, Termination ID = T2] 



7. H.248 : ADD.req [Context ID = CI, Termination ID = ?] 



8. H.248 : ADD.resp [Context ID = CI, Termination ID = T1] 



14. BICC: COT 



15. BICC : ACM 



19. BICC : ANM 



20. H.248 : MOD.req [Context ID = C1, Termination ID = T1] 



21. H.248 : MOD.resp [Context ID = CI, Termination ID = T1] 



Bearer Establishment 



Change IMS 
Through-Connection = both 



CALL IN ACTIVE STATE 



Figure B.1 : Basic IIUI CN Subsystem originating session, BICC forward bearer establishment 

(message sequence chart) 
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B.3.2 Basic CS network originated session 

This subclause shows an example of the interworking of codec negotiation between a BICC CS network and an IM CN 
subsystem during session establishment for a BICC CS network originated session. The example applies to BICC 
forward bearer establishment. Similar procedures apply to the other four versions of bearer establishment procedure 
applicable to the BICC CS network. The exchange of codec information is identical in all five cases, but there are 
differences in the sequence of operations associated with bearer establishment within the BICC CS network. 

B.3.2. 1 BICC forward bearer establishment 
B.3.2.1.1 IM-MGW selection 

The MGCF shall select an IM-MGW for the bearer connection before it performs the IM CN subsystem session 
establishment or the CS network side bearer establishment. 

B.3.2.1 .2 IM CN subsystem side termination reservation 

The MGCF shall derive from the codec negotiation procedure one or several appropriate local codec(s) the IM-MGW 
may use to receive user plane data from the IM CN subsystem. The MGCF shall use the Reserve IMS Connection Point 
procedure (signals 2 and 3 in figure B.2/1). Within this procedure, the MGCF shall indicate the local codec(s) and 
request a local IP address and UDP port from the IM-MGW. The local IP address and UDP port are used by the IM- 
MGW to receive user plane data from the IM CN subsystem. If DTMF support together with speech support is required, 
or if the resources for multiple speech codecs shall be reserved at this stage, the reserve value indicator shall be set to 
"true". 

The IM-MGW shall reply to the MGCF with the selected local codec(s) and the selected local IP address and UDP port. 

The MGCF shall send this information in the INVITE (signal 4 in figure B.2/1) to the IM CN subsystem. 

B.3.2.1 .3 IM CN subsystem side session establishment 

The MGCF shall use the Configure IMS Resources procedure (signals 7 and 8 in figure B.2/1) to provide configuration 
data (derived from SDP received in signal 6 in figure B.2/1 and the codec negotiation procedure) to the IM-MGW as 
detailed below: 

The MGCF shall indicate the remote IP address and UDP port, i.e. the destination IP address and UDP port for 
data sent in the user plane towards the IM CN subsystem. 

The MGCF shall indicate the remote codec(s), i.e. the speech codec(s) for data sent in the user plane towards the 
IM CN subsystem. 

The MGCF may indicate the local codec(s) and the local IP address and UDP port. The MGCF shall indicate the 
local codec(s) if a change is required. 

IF DTMF support together with speech support is required, the reserve value indicator shall be set to "true". 

The IM-MGW shall reply with the selected remote codec(s) and reserve resources for these codec(s). If local codec(s) 
were received, the IM-MGW shall also reply with the selected local codec(s) and reserve the corresponding resources. 

If the selected local codec(s) differ from the codec(s) received in the SDP of signal 6 in figure B.2/1, the MGCF shall 
send the local reserved codec(s), and the local IP address and UDP port in the PRACK (signal 9 in figure B.2/1) to the 
IMS. 

B.3.2.1 .4 CS network side bearer establishment 

The MGCF shall request the IM-MGW to prepare for the CS network side bearer establishment using the Prepare 
Bearer procedure (signals 1 1 and 12 in figure B.2/1). Within this procedure, the MGCF shall request the IM-MGW to 
provide a bearer address, a binding reference and optionally notify when the bearer is established. The MGCF shall also 
provide the IM-MGW with the bearer characteristics determined by the codec negotiation procedure. After the IM- 
MGW has replied with the bearer address and the binding reference, the MGCF provides the APM message (signal 13 
in figure B.2/1) to the preceding node. The MGCF may also provide the IM-MGW-id in the APM message. 
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B.3.2.1 .5 Called party alerting 

The MGCF shall request the IM-MGW to provide an awaiting answer indication (ringing tone) to the calling party 
using the Send Tone procedure (signals 21 and 22 in figure B.2/1), when the following condition is satisfied: 

the MGCF receives the first 180 Ringing message 

B.3.2.1 .6 Called party answer 

When the MGCF receives a 200 OK message (signal 23 in figure B.2/2), it shall request the IM-MGW to stop providing 
the ringing tone to the calling party using the Stop Tone procedure (signals 26 and 27 in figure B.2/2). 

B.3.2.1. 7 Through-Connection 

During the Prepare Bearer procedure, the MGCF shall either use the Change Through-Connection procedure to request 
the IM-MGW to backward through-connect the BICC termination, or the MGCF shall use this procedure to both-way 
through-connect the BICC termination already on this stage (signals 1 1 and 12 in figure B.2/1). During the Reserve 
IMS Connection Point procedure, the MGCF shall use the Change IMS Through-Connection procedure to request the 
IM-MGW to backward through-connect the IMS termination (signals 2 and 3 in figure B.2/1). 

When the MGCF receives the SIP 200 OK(INVITE) (signal 23 in figure B.2/2), it requests the IM-MGW to both-way 
through-connect the terminations using the Change IMS Through-Connection or Change Through-Connection 
procedures (signals 28 and 29 in figure B.2/2), unless those terminations are already both-way through-connected. 

B.3.2.1. 8 Codec handling 

The IM-MGW may include a speech transcoder based upon the speech coding information provided to each 
termination. 

B.3.2.1 .9 Failure handling in MGCF 

If any procedure between the MGCF and the IM-MGW is not completed successfully, the default action by the MGCF 
is to release the session as described in subclause 9.2.6. If the MGCF receives a Bearer Released procedure from the 
IM-MGW the default action by the MGCF is to release the session, as described in subclause 9.2.7. 

NOTE: As an implementation option the MGCF may also decide for example to only release the resources in the 
IM-MGW that caused the failure, possibly select a new IM-MGW for the connection and continue the 
call establishment using new resources in the selected IM-MGW but such handling is outside of the scope 
of the present document. 

B.3.2.1 .10 Message sequence chart 

Figures B.2/1 and B.2/2 show the message sequence chart for the CS network originating session with BICC forward 
bearer establishment. 
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IM-MGW 



MGCF 



1 . BICC : lAM [supported codec list 1] 



Configure IMS Resources 



2. H.248 : ADD.req [Context ID = ?, Termination ID=?] 



3. H.248 : ADD.resp [Context ID = C1 , Termination ID = T1] 



7. H.248 : MOD.req Context ID = C1 .Termination ID = T1] 



8. H.248 : MOD.resp [Context ID = CI , Termination ID = T1 ] 



1 1 . H.248 : ADD.req [Context ID = CI , Termination ID = ?] 



12. H.248 : ADD.resp [Context ID = CI, Termination ID = T2] 



13. BICC : APM [selected codec 1, available codec list 1] 



Bearer Establishment 



14. BICC: COT 



20. BICC : ACM 



21 . H.248 : MOD.req [Context ID = CI , Termination ID = T2] 



22. H.248 : MOD.resp [Context ID = CI , Termination ID = 12] 



Reserve IMS Connection Point, 
Change IMS Through- 
Connection = backward 

4. SIP: INVITE 
[supported codec list 2] 



5. S!E: 100 Trying 



6. SIP:183 
[available codec list 2] 



9. S!P: PRACK 
[selected codec 2] 



10.S!P:200OK (PRACK) 
[selected codec 2] 



Prepare Bearer, 
Change Through- 
Connection^ both 



15. SIP: UPDATE 



♦- 
*- 


16 


SIP 


.:200 OK (UPDATE) 




17. 


SIP:180 Ringing 




18. 


SIP: PRACK 


^-. 


19. 


SIP 


:200 OK (PRACK) 



Send Tone 



Figure B.2/1 : Basic CS Networit Originating Session, BICC forward bearer establishment 

(message sequence chart) 
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24. H.248 : MOD.req [Context ID=C1, Termination ID : 
T2] 



25. H.248 : IVIOD.resp [Context ID = C1, Termination ID = T2] 



26. H.248 : MOD.req [Context ID=C1, Termination ID : 
T1] 



27. H.248 : MOD.resp [Context ID = C1, Termination ID = T1] 



28. BICC: ANM 



23. S!P:200 OK (INVITE) 



Stop Tone 



Change IMS 
Through-Connection = both 



29. SIP: ACK 



CALL IN ACTIVE STATE 



Figure B.2/2: Basic CS Network Originating Session, BICC forward bearer establishment 

(message sequence chart continued) 
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B.3.3 CS network initiated mid-call codec negotiation 

Figure B.3 shows the CS network initiated mid-call codec negotiation procedure interworking with the IM CN 
subsystem. When the MGCF selects the codecs for the CS network and the IM CN subsystem (after signal 3 in figure 
B.3), the MGCF shall modify the CS network termination and the IM CN subsystem termination on the IM-MGW to 
conform to the newly selected configuration data on the two interfaces. The MGCF may perform bearer operations (not 
shown) at the IM-MGW before interworking the initial codec modification request (signal 2 in figure B.3) to determine 
new connection information, if necessary, or to verify resource availability. 



IM-MGW 



MGCF 



1 . BICC : APM [supported codec list 1] 



Configure IMS Resources 



Modify Bearer Cfiaracteristics 



4. H.248 : MOD.req Context ID = C1, Termination ID = T1] 



5. H.248 : MOD.resp [Context ID = CI , Termination ID = T1 ] 



6. H.248 : MOD.req [Context ID = CI , Termination ID = 12] 



7. H.248 : MOD.resp [Context ID = CI , Termination ID = T2] 



9. BICC : APM [selected codec 1] 



1 0. BICC : APM [action = successful codec modification] 



2. SIP: re-INVITE 
[supported codec list 2] 



3. S!P:200 OK (INVITE) 
[selected codec 2] 



8. S!P: ACK 



Figure B.3: CS network initiated mid-call codec negotiation 
(message sequence chart) 
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B.3.4 IM CN subsystem initiated mid-call codec negotiation 

Figure B.4 shows the IM CN subsystem initiated mid-call codec negotiation procedure interworking with a BICC CS 
network. When the MGCF selects the codecs for the CS network and the IM CN subsystem (after signal 3 in figure 
B.4), the MGCF shall modify the CS network termination and the IM CN subsystem termination on the IM-MGW to 
conform to the newly selected configuration data on the two interfaces. The MGCF may perform bearer operations (not 
shown) at the IM-MGW before interworking the initial codec modification request (signal 2 in figure B.3) to determine 
new connection information, if necessary, or to verify resource availability. The MGCF may also perform bearer 
operations (not shown) at the IM-MGW after sending the final APM (signal 8 in figure B.4) to modify transport 
bandwidth, if necessary. 



IM-MGW 



2. BICC : APM [supported codec list 2] 



3. BICC : APM [supported codec list 2] 



Configure IMS Resources 



Modify Bearer Characteristics 



4. H.248 : MOD.req Context ID = C1 Termination ID = T1] 



5. H.248 : MOD.resp [Context ID = CI , Termination ID = T1 ] 



6. H.248 : MOD.req [Context ID = CI , Termination ID = T2] 



7. H.248 : MOD.resp [Context ID = CI , Termination ID = 12] 



8. BICC : APM [action = successful codec modification] 



1.SIP:re-INVITE 
[supported codec list 1] 



9. S!P:200 OK (INVITE) 
[selected codec 1] 



10. SIP:ACK 



Figure B.4: IM CN subsystem initiated mid-call codec negotiation 
(message sequence chart) 
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Annex C (normative): 
Interworking of CPC parameter 



The CPC extension to tel-URI Parameter is defined in subclause 7.2A.12 of 3GPP TS 24.229 [9]. The SIP "Accept- 
Language" header is defined in IETF RFC 3261 [19]. 



C.1 Interworking SIP to ISUP 



Table C.1,1 shows the mapping of a "cpc" URI parameter received within tel URI or the userinfo part of SIP URI with 
user="phone" in a P-Asserted-Identity header in the initial INVITE request to the Calling party's category parameter in 
the ISUP lAM. When the "cpc" URI parameter value "operator" is received the I-MGCF shall use an Accept-Language 
header field to determine the value of the Calling party's category parameter. 

Table C.1,1 : Mapping of the CPC parameter to the ISUP Calling party's category parameter 



SIP Parameters 


ISUP Parameters 


"cpc" URI parameter In 
P-Asserted-ldentlty (NOTE 2) 


Accept- 
Language 


Calling party's category 


operator 


fr 


operator, language French 


operator 


en 


operator, language English 


operator 


de 


operator, language German 


operator 


ru 


operator, language Russian 


operator 


es 


operator, language Spanish 


ordinary 




ordinary calling subscriber 


test 




test call 


payphone 




payphone 


unknown 




calling party's category unknown at this time (national use) 


mobile-hpimn 




mobile terminal located in the home PLIVIN 


mobile-vpimn 




mobile terminal located in a visited PLIVIN 


emergency 




emergency service call per ANSI Standard ATIS-1 0001 13.2005 [117] 
(N0TE1) 


NOTE 1 : This is a national/regional specific value. lnterworl<ing shall only occur when interconnecting with indicated 

national network. 
NOTE 2: In case the "cpc" URI parameter is absent or contains values that are not mapped per this table then the 

ISUP shall contain the default CPC value "ordinary calling subscriber". 



In case the Accept-Language header field is not received or contains values that are not in this table then based on 
operator policy the Calling party's category parameter shall contain the CPC value "operator, language X" (where X is 
one of the following languages: French, English, German, Russian or Spanish) or national/regional specific value. 
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C.2 Interworking ISUP to SIP 



Table C.2,1 shows the mapping of a Calling party's category received in an ISUP lAM to a "cpc" URI parameter within 
tel URI or the userinfo part of SIP URI with user="phone" in the P-Asserted-Identity header. When the Calling party's 
category parameter value "operator, language x" is received the O-MGCF shall generate an Accept-Language header 
field with the value that corresponds to language x. 

Table C.2,1 : Mapping of the ISUP Calling party's category parameter to the CPC parameter 



ISUP Parameter 


SIP Parameters | 


calling party's category 


"cpc" URI parameter in 
P-Asserted-ldentity 


Accept- 
Language 


operator, language French 


operator 


fr 


operator, language English 


operator 


en 


operator, language German 


operator 


de 


operator, language Russian 


operator 


ru 


operator, language Spanish 


operator 


es 


ordinary calling subscriber 


ordinary 


- 


test call 


test 


payphone 


payphone 


calling party's category unknown at this time(national use) 


unknown 


mobile terminal located in the home PLMN 


mobile-hpimn 


mobile terminal located in a visited PLIVIN 


mobile-vpimn 


emergency service call per ANSI Standard ATIS-1 0001 1 3.2005 [1 1 7] 
(N0TE1) 


emergency 


NOTE 1 : This is a national/regional specific value. Interworking shall only occur when interconnecting with indicated 

national network. 
NOTE 2: In case the calling party"s category contains values that are not in this table then based on operator policy 

the "cpc" URI parameter may be omitted or may contain national/regional specific value. 
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Annex D: 
Void 
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Annex E (normative): 

Multimedia interworking between the IP IVIultimedia Core 

Network (CN) Subsystem (IIVIS) and Circuit Switched (CS) 

networks 



E.1 Basic IVIultimedia calls interworking between the IMS 
and CS Networks scenarios 

The Interworking between Circuit switched multimedia telephony service, as described in 3GPP TS 26.1 10 [78] and 
3GPP TS 26.1 1 1 [79], and packet switched multimedia services, as described in 3GPP TS 26.235 [80] and 
3GPP TS 26.236 [32] is addressed. 

3GPPTS 26.111 



Video I/O 
Equipment 



Audio I/O 
Equipment 



User Data 
Applications 
[T.120, ...] 



System 
Control 



Video Codec 

H.263, [MPEG-4, H.261 



Speech Codec 
3GPP-AMR, 
[G.723.1 ...] 



Optional 
Receive Path 
Delay 



Data Protocols 
[V.14, LAPM, . 




Multiplex/ 
Demultiplex 
H.223, 

H.223 Annex 
A, H.223 
Annex B, 
[H.223 Annex 
C, H.223 
Annex D] 



Optional 
Multilink 

H.324 
Annex H 



Call Set-up 



3GPP 

Network 



Figure E. 1.1.1 Overview of relevant CS-Domain Protocols (from 3GPP TS 26.110 [78]) 
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E.2 Control plane interworking 
E.2.1 General 

In addition to the control plane Interworking between SIP and ISUP or BICC, interactions between the H.245 signalling 
at the CS side and SIP/SDP signalling are described. 

The establishment of the H.223 multiplexing protocol and the subsequent H.245 signalling procedures take place after 
the set-up and both-way through-connection of the CS bearer. 

E.2. 2 Functionalities required in the MGCF for multimedia calls 
support 

In addition to the control plane Interworking between SIP and ISUP or BICC, the MGCF needs to mediate interactions 
between the H.245 signalling or MONA (Media Oriented Negotiation Acceleration) procedures at the CS side and 
SIP/SDP signalling at the IMS side. The interactions between H.245 signalling or MONA procedures and SIP/SDP 
signalling should aim at avoiding media transcoding by selecting the same codec for the CS side and the PS side. 

NOTE: Detailed procedures for the mapping between SDP parameters and H.245 parameters are not specified in 
the present release. 

E.2. 3 IM CN subsystem originated session 

E.2. 3.1 Preconditions used at IIVIS side 

E.2.3.1 .1 Interactions between H.245 or MONA and SIP/SDP 

Figure E.2. 3. 1.1.1 shows examples of interactions between H.245 or MONA procedures and SIP/SDP for IM CN 
subsystem originated session. Most SIP and ISUP or BICC messages are intentionally omitted, since the SDP may be 
embedded in various SIP messages and since the in-band H.245 Messages are not tightly coupled with out-of-band 
ISUP or BICC messages. 

Figure E.2. 3. 1.1.1 assumes that the IMS peer uses the SIP precondition extension to indicate that preconditions have not 
yet been met. 
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IMS 



Interworking Node 
(MGCF+ IM MGW) 



1. SIP: INVITE 

[SDR offer:, 

m = H.263, MP4V-ES, H.261; 

m=AMR, 

Preconditions not met] 



3. SIP: 

[SDR answer: 

m = H.263; 

m=AUR, 

Preconditions not met ' 



10. S!P: 200 OK (INVITE) 



11. SIP: 

[SDR offer; m =: IVIR4V-ES; a= 
3gpp_l\/laxRecvSDUSize 600; m= AIVIR ] 

i"2".""si"p"":" 

[SDR answer; m = l\/IR4V-ES, m= AIVIR] 



CS Network 



2. lAM 



4. Bearer Establishment 



5. ANM 



6. H.223 Bearer Setup including possible MONA Channel 
establishment method negotiation 



Alternative to 7-9: MONA messages 



7. H.245: Terminal Capability Set 

[H.263, MR4V-ES; H.261 
AMR] 



8. H.245: Terminal Capability Set 

[H.261, MP4V-ES; 
AMR, G. 711] 

9. H.245: Open Logical Channels 

[MP4V-ES, AMR] 



CALL IN ACTIVE STATE 



Figure E.2.3. 1.1.1 : Interactions between 1-1.245 and SIP/SDP for IIV! CN subsystem originated session 

IIVIS peer indicates unmet local preconditions 

Upon receipt of a SIP INVITE request containing speech and video Codecs (signal 1 in figure E.2.3. 1.1.1) the 
Interworking Node (consisting of MGCF and IM-MGW) starts the call set-up for multimedia call at the CS side by 
sending an lAM requesting an UDI bearer (signal 2 in figure E.2.3. 1.1.1). 

If SDP local preconditions, which are not yet met, are contained in signal 1, the Interworking node should immediately 
send an SDP answer to allow for the IMS-side bearer set-up to progress. The Interworking node selects codecs 
supported by the IM-MGW and likely to be supported within the CS network and communicates the selected codecs 
towards the IMS side within an SDP answer message (signal 3 in figure E.2.3. 1.1.1). If theses codecs are contained in 
the SDP offer, the Interworking Node should select the H.263 codec and may select other codec from the SDP offer in 
addition. The interworking node should include a b:AS bandwidth modifier with a bandwidth suitable for the selected 
codec(s), but not higher than 64kbit/s plus RTP/UDP/IP overhead, in the SDP answer to request that the peer does not 
send media with a higher bandwidth. 

The Interworking Node shall engage in an H.223 bearer setup (step 6 in figure E.2.3. 1.1.1). If the interworking Node 
supports MONA (Media Oriented Negotiation Acceleration), it shall first attempt a MONA Channel establishment 
method negotiation according to Annex K of ITU-T Recommendation H.324 [81]. If the interworking node does not 
support MONA, it shall use the multiplexing level negotiation procedures of Annex C of H.324 [81]. If the 
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Interworking Node supports MONA, but the remote peer does not do so, a fallback to the multiplexing level negotiation 
procedures of Annex C of H. 324 [81] will occur. 

If both the Interworking Node and the remote CS terminal support MONA procedures, the MONA procedures as per 
ITU-T Recommendation H.324 Annex K [81] may be used to replace the H.245 negotiation (signals 7 - 9) as shown in 
figure E.2.3. 1.1.1. 

If MONA procedures are not used, the following applies: 

After the completion of the H.223 bearer setup at the CS side, the Interworking Node shall send a Terminal 
Capability Set message describing its own capabilities (signal 7 in figure E.2.3. 1.1.1). Unless the Interworking 
Node supports transcoding, the Interworking Node shall only send codecs that have been offered at the IM CN 
subsystem side (as received in signal 1 in figure E.2.3. 1.1.1) within this message. 

The Interworking Node will receive an H.245 Terminal Capability Set message describing the supported Codecs 
at the peer's side (signal 8 in figure E.2.3. 1.1.1). 

The codecs contained both in the sent and received terminal capability set messages may be selected at the CS 
side. The final decision of the selected codecs at the CS side is taken when the H.245 open logical Channels 
message (signal 9 in figure E.2.3. 1.1.1) is sent or received. The direction of this message is determined by the 
H.245 master-slave determination procedure. 

If the Interworking Node does not transcode, it should indicate the codecs selected within the H.245 negotiation 
(signal 11 in figure E.2.3. 1.1.1) or within the MONA procedures and enable any media that have previously been put on 
hold at the IMS side after the completion of the H.245 negotiation or MONA procedures. 

The interworking node should include in step 11 of figure E.2.3. 1.1.1 the SDP "a" attribute "3gpp_MaxRecvSDUSize" 
indicating the maximum SDU size of the application data that can be transmitted to the receiver without segmentation, 
as specified in subclause 12.2.4.6 of 3GPPTS 26.114 [104]. 



E.2.3. 2 Preconditions not used at IMS side 

E.2.3.2.1 Interactions between H.245 or MONA and SIP/SDP 

Figure E.2.3.2.1. 1 shows examples of interactions between H.245 or MONA procedures and SIP/SDP for IM CN 
subsystem originated session. Most SIP and ISUP or BICC messages are intentionally omitted, since the SDP may be 
embedded in various SIP messages and since the in-band H.245 Messages are not tightly coupled with out-of-band 
ISUP or BICC messages. 

Figure E.2.3.2.1.1 assumes that the IMS peer does not use the SIP precondition extension. 
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IMS 



Interworking Node 
(MGCF+ IM MGW) 



1.SIP: INVITE 

[SDP offer:, 

m = H.263, MP4V-ES, H.261; 

m=AMR] 



9. SIP: 200OK (INVITE) 

[SDP answer: 

m = MP4V-ES; a= 3gpp_MaxRecvSDUSize 600; 

m=AMR] 



CS Network 



2. lAM 



3. Bearer Establishment 



4. ANM 



5. H.223 Bearer Setup including possible 
MONA CInannel establishment method negotiation 



Alternative to 6-8: MONA messages 



6. H.245: Terminal Capability Set 

[MP4V-ES; AMR] 



7. H.245: Terminal Capability Set 

[H.261, MP4V-ES; 
AMR, G. 711] 



H.245: Open Logical Channels 

[MP4V-ES, AMR] 



CALL IN ACTIVE STATE 



Figure E.2.3.2.1.1 Interactions between H.245 and SIP/SDR for IIV! ON subsystem originated session 

IIVIS peer does not use SIP preconditions. 

Upon receipt of a SIP INVITE request containing speech and video Codecs (signal 1 in figure E.2.3.2.1.1) the 
Interworking Node (consisting of MGCF and IM-MGW) starts the call set-up for multimedia call at the CS side by 
sending an lAM requesting an UDI bearer (signal 2 in figure E.2.3.2.1.1). 

If no unmet local SDP preconditions are contained in signal 1, the Interworking node should defer sending an SDP 
answer until the H.245 negotiation or MONA procedures is/are completed. 

The Interworking Node shall engage in an H.223 bearer setup (step 5 in figure E.2.3.2.1.1). If the interworking Node 
supports MONA (Media Oriented Negotiation Acceleration), it shall first attempt a MONA Channel establishment 
method negotiation according to Annex K of ITU-T Recommendation H.324 [81]. If the interworking node does not 
support MONA, it shall use the multiplexing level negotiation procedures of Annex C of H.324 [81]. If the 
Interworking Node supports MONA, but the remote peer does not do so, a fallback to the multiplexing level negotiation 
procedures of Annex C of H.324 [81] will occur. 

If both the Interworking Node and the remote CS terminal support MONA procedures, the MONA procedures as per 
ITU-T Recommenation H.324 [81] Annex K may be used to replace the H.245 negotiation (signals 6 - 8) as shown in 
figure E.2.3.2.1.1. 

If MONA procedures are not used, the following applies: 
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After the completion of the H.223 bearer setup at the CS side, the Interworking Node shall send a Terminal 
Capability Set message describing its own capabilities (signal 6 in figure E.2.3.2.1.1). Unless the Interworking 
Node supports transcoding, the Interworking Node shall only send codecs that have been offered at the IM CN 
subsystem side (as received in signal 1 in figure E.2.3.2.1.1) within this message. 

The Interworking Node will receive an H.245 Terminal Capability Set message describing the supported Codecs 
at the peer's side (signal 7 in figure E.2.3.2.1.1). 

The codecs contained both in the sent and received terminal capability set message may be selected at the CS 
side. The final decision of the selected codecs at the CS side is taken when the H.245 open logical Channels 
message (signal 8 in figure E.2.3.2.1.1) is sent or received. The direction of this message is determined by the 
H.245 master-slave determination procedure. 

If the Interworking Node does not transcode, it shall send an SDP answer (signal 9 in figure E.2.3.2.1.1) indicating the 
codecs selected within the H.245 negotiation or within the MONA procedures after the completion of the H.245 
negotiation or MONA procedures. The interworking node should include a b: AS bandwidth modifier with a bandwidth 
suitable for the selected codec(s), but not higher than 64kbit/s plus RTP/UDP/IP overhead, in the SDP answer to request 
that the peer does not send media with a higher bandwidth. 

The interworking node should include in Step 9 of figure E.2.3.2.1.1 the SDP "a" attribute "3gpp_MaxRecvSDUSize" 
indicating the maximum SDU size of the application data that can be transmitted to the receiver without segmentation, 
as specified in subclause 12.2.4.6 of 3GPPTS 26.114 [104]. 

E.2.3.3 Fallback to speech at session establishment 

If SCUDIF Fallback (see 3GPP TS 23.172 [121]) occurs on the CS side, the APM message contains a speech codec as 
"Selected Codec". The MGCF shall then disable the video "m-line" in the first SDP answer, if not yet sent, and 
complete the call-setup in the same way as for a normal speech call. If the SDP answer was already sent (precondition 
used), the MGCF shall update the SIP session to speech by sending a SIP UPDATE message with a relevant SDP. 

If in a non-SCUDIF case (ISUP or BICC without SCUDIF) the called CS terminal or network rejects the video call 
setup by sending a REL message to the MGCF, the MGCF releases the CS video call being established, re-establishes 
the CS call in a speech only mode sending a new lAM with a speech BCIE to the CS network and updates the IM CN 
leg codecs to a speech only codec. Then the call/session continues as in a speech only case. If the interworking node 
does not support the fallback, it shall release the session. 

E.2.4 CS network originated session 

E. 2.4.1 Interactions between SIP/SDP and H.245 or IVIONA 

E.2.4.1.1 Normal Call setup 

Figure E.2.4.1.1 shows examples of interactions between H.245 or MONA and SIP/SDP for the CS network originated 
session. Most SIP and ISUP or BICC messages are intentionally omitted, since the SDP may be embedded in various 
SIP messages and since the in-band H.245 Messages are not tightly coupled with out-of-band ISUP or BICC messages. 
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CALL IN ACTIVE STATE 



NOTE: Messages 3 and 5 may be combined in some scenarios. 
Figure E.2.4.1.1 : Interactions between 1-1.245 and SIP/SDP for CS networit originated session 

Upon receipt of an lAM request for a multimedia Call (signal 1 in figure E.2.4.1.1) the Interworking Node (consisting 
of MGCF and IM-MGW) starts the call set-up for multimedia call at the IM CN subsystem side by sending an INVITE 
request (signal 2 in figure E.2.4.1.1). For the INVITE request, the Interworking Node selects codecs supported by the 
IM-MGW and likely to be supported within the CS Network. The Interworking Node should select the H.263 codec and 
may select other codec in addition. The interworking node should add a b:AS bandwidth modifier with a bandwidth 
suitable for the selected codec(s), but not higher than 64kbit/s plus RTP/UDP/IP overhead, in the SDP offer to request 
that the peer does not send media with a higher bandwidth. 
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NOTE: The SDP coding to express that either a combined voice and video call, or a voice call, or a Clearmode 
codec, or some other data call is desired is not defined in the present release. 

The Interworking Node shall engage in an H.223 bearer setup (step 7 in figure E.2.4.1.1). If the interworking Node 
supports MONA (Media Oriented Negotiation Acceleration), it shall first attempt a MONA Channel establishment 
method negotiation according to Annex K of ITU-T Recommendation H.324 [81]. If the interworking node does not 
support MONA, it shall use the multiplexing level negotiation procedures of Annex C of H.324 [81]. If the 
Interworking Node supports MONA, but the remote peer does not do so, a fallback to the multiplexing level negotiation 
procedures of Annex C of H.324 [81] will occur. 

If both the Interworking Node and the remote CS terminal support MONA procedures, the MONA procedures as per 
ITU-T Recommendation H.324 [81] Annex K may be used to replace the H.245 negotiation (signals 8, 1 1 and 12) as 
shown in figure E.2.4.1.1. Furthermore, the SIP codec renegotiation in signals 9 and 10 is then also not applicable. 

If MONA procedures are not used, the following applies; 

After the completion of the H.223 bearer setup at the CS side the Interworking Node will receive a H.245 
Terminal Capability Set message describing the supported Codecs at the peer's side (signal 8 in figure E.2.4.1.1). 

Due to information received in a Terminal Capability Set message (signal 8 in figure E.2.4.1.1), the Interworking 
node may send an SDP offer at the IMS side (signal 9 in figure E.2.4.1.1), to offer additional codecs supported at 
the CS side but not contained in the first SDP offer (signal 2 in figure E.2.4.1.1), or to restrict the selected codecs 
at the IMS side to codecs which are available at the CS side. 

NOTE: It is not clear if the addition of codecs not included in previous SDP exchange has any impacts on IMS 
procedures, e.g. resource reservation related procedures. 

The Interworking Node shall send a Terminal Capability Set message describing its own capabilities (signal 1 1 
in figure E.2.4.1.1). Unless the Interworking Node supports transcoding, the Interworking node shall only send 
codecs that are also negotiated at the IM CN subsystem side (as received in signal 3 in figure E.2.4.1.1) within 
this message. The Interworking Node may defer sending the Terminal Capability Set message for some time to 
attempt to receive the peer's Terminal Capability set message and perform a possible IMS-side codec re- 
negotiation. However, to avoid blocking situations, the Interworking Node shall not defer sending the Terminal 
Capability Set message for an excessive period of time. 

The codecs contained both in the sent and received Terminal Capability Set message may be selected at the CS 
side. The final decision of the selected codecs at the CS side is taken when the H.245 open logical Channels 
message (signal 12 in figure E.2.4.1.1) is sent or received. The direction of this message is determined by the 
H.245 master-slave determination procedure. 

If the Interworking Node does not transcode, it should indicate the codecs selected within the H.245 negotiation or 
within MONA procedures after the completion of the H.245 negotiation (signal 13 in figure E.2.4.1.1) or MONA 
procedures. 

The interworking node should include in Step 11 of figure E.2.4.1.1 the SDP "a" attribute "3gpp_MaxRecvSDUSize" 
indicating the maximum SDU size of the application data that can be transmitted to the receiver without segmentation, 
as specified in subclause 12.2.4.6 of 3GPPTS 26.114 [104]. 

E. 2.4.1 .2 Call setup if multimedia call can not be recognized in an unambiguous 
manner 

If the Interworking Node is not able to determine from the information within the lAM request whether a multimedia 
call or some other type of data call is requested (for example, if only TMR=UDI but no BC IE is contained in the lAM), 
the Interworking Node may also include appropriate codecs for other possible types of data call it supports in the 
INVITE request. If video and audio codecs are contained in the first SDP answer (signal 3), the Interworking Node 
should continue to attempt to set up a multimedia call as described in subclause E.2.4.1.1. Otherwise, calls are set up as 
described in subclause 7.2.3.2. 

E. 2.4.1 .3 Fallback to speech during call setup 

The called party can reject the video component in the SDP offer (signal 2 in figure E.2.4.1.1) by returning an SDP 
answer where the video related m-line is disabled (in signal 3 in figure E.2.4.1.1). 
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If the MGCF receives an SDP answer during call setup where the video related m-line is disabled, it shall react as 
follows; 

If the MGCF has received a SCUDIF call setup from the CS side (MuMe and speech codecs in lAM message, 
see 3GPP TS 23.172 [121]), the MGCF shall apply a SCUDIF fallback to speech on the CS side. The MGCF 
shall use a speech codec as Selected Codec and exclude the MuMe codec from the available codec list. 

If the MGCF has received a multimedia call setup without SCUDIF from the CS side, and the CS network 
supports CS fallback, the MGCF should terminate the call. 

NOTE 1 : A call termination can trigger the caller's device to set up a new speech call. 

NOTE 2; Other procedures to maintain the CS call, e.g. disabling the video component on the CS side or providing 
a suitable video announcement and discarding received video media from the CS side, are FFS. 



E. 2.4.2 CS originated - IM CN transit - CS terminated 

Figure E.2.4.2.1 describes ISUP and SIP/SDP interactions in a CS originated - IM CN transit - CS terminated case with 
a clear channel through the IM CN. An interworking node A receives an lAM message with a UDI H.223 & H.245 
video call request (message 1). If the interworking node A supports both CS/IMS video interworking and a clearmode 
codec / clear channel, it may send both audio and video codecs and a clearmode codec and a UDI & H.223 & H.245 
video indication in the INVITE message towards the IMS (message 2). The message is received by an interworking 
node B. The interworking node B sends an I AM message with a UDI & H.223 & H.245 video call request to the 
terminating CS network (message 3). If the interworking node B supports a clearmode codec / clear channel, it may 
send a SIP response with a clearmode codec towards the calling side to indicate that a clear channel can be established 
between the IMS interworking nodes (message 5). After the called party answers, the interworking node B sends a SIP 
200 OK (Invite) with the clearmode codec to the calling node to indicate that a clear channel can be established 
(message 1 1). After the called party has answered the call, either MONA procedures are performed and the H.223 
bearer is established or the H.223 bearer is established and the H.245 signalling is performed (step 14 in figure 
E.2.4.2.1). 

If the interworking node A does not support CS-IMS video interworking, but supports a clearmode codec / clear 
channel, it sends the INVITE message with a clearmode codec and UDI & H.223 & H.245 indication, but without a 
video codec, to allow the establishment of a CS video call through a clear channel. The interworking node A may also 
send an audio codec (alone or with a clearmode codec) to allow a fallback to speech. The interworking node B either 
accepts the clearmode and sends the corresponding lAM message with a UDI & H.223 & H.245 request (message 3) 
and SIP response with a clearmode codec (message 5 or 1 1), or accepts the speech mode and sends the corresponding 
lAM message with a speech request (message 3) and SIP response with a speech codec (messages 5, 11), or rejects the 
INVITE message if the requested codec(s) cannot be supported. 

NOTE: The format of the indication of UDI & H.223 & H.245 from interworking node A to interworking node B 
is not defined in the present release. 
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CALL IN ACTIVE STATE 



Figure E.2.4.2.1 : ISUP and SIP/SDP interactions in a CS originated - IIU! CN transit 
- CS terminated case withi a clear channel through the IIVI CN 

E.2.5 Service change 

E.2.5.2.1 SCUDIF 
E.2.5. 2. 1.0 General 

SCUDIF is standardised in 3GPPP TS 23.172 [121]. 

E.2.5.2.1 .1 IM CN subsystem originated change 

E.2.5.2.1 .1 .1 Change from multimedia to speech 

Figure E.2.5.2.1. 1.1.1 shows an IM CN subsystem originated modification from multimedia to speech during an 
ongoing session when the CS leg supports BICC. The interworking node receives an INVITE message that indicates the 
dropping of the video media from the session, message 1 . The interworking node can only accept the dropping of the 
media component and sends a corresponding codec modification request to the BICC network, message 2, and 
acknowledges the INVITE with a 200 OK message. The BICC network indicates a successful codec modification, 
message 5. 
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5. Successful Codec Modification 
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Figure E.2.5.2. 1.1.1.1: IM CN subsystem originated modification 
from multimedia to speech when the CS leg supports BICC 

Editor's note: Handling of a case, where a codec is received in BICC negotiation but not included in the available 
codec hst negotiated previously, is ffs. 



E.2.5.2. 1.1. 2 



Change from speech to multimedia 



Figure E.2.5.2. 1.1. 2.1 shows an IM CN subsystem originated modification from speech to multimedia during an 
ongoing session when the CS leg supports BICC. The interworking node receives an INVITE message that offers the 
adding of a video media to the ongoing speech session, message 1 . The interworking node accepts the offer and sends a 
corresponding codec modification request to the BICC network, message 2. The BICC network indicates a successful 
codec modification, message 3. The interworking node acknowledges the INVITE with a 200 OK message after the 
MONA or H.245 in-band negotiation in step 4 is completed. 

If the codec modification is not successful in the BICC network, the interworking node responds to the INVITE 
message with the speech codec in the 200 OK message to retain the speech only session. 
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Figure E.2.5.2.1 .1.2.1: IM CN subsystem originated modification 
from speech to multimedia when the CS leg supports BICC 
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E.2.5.2.1.2 



CS network originated change 



E.2.5.2. 1.2.1 



Change from multimedia to speecin 



Figure E.2.5.2. 1.2. 1.1 shows a CS network originated modification from multimedia to speech during an ongoing 
session when the CS leg supports BlCC. The interworking node receives a Modify Codec message that indicates the 
dropping of the video media from the session, message 1 . The interworking node accepts the dropping of the video 
component and sends a corresponding INVITE message to the IM CN subsystem, message 2, and acknowledges the 
codec modification request to the BlCC network, message 3. The IM CN subsystem acknowledges the INVITE 
dropping the video media with a 200 OK, message 4. 



IMS 
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(MGCF-f IM MGW) 



CS Network 
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4. S!P: 200 OK (INVITE) [m= AMR] 
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E.2.5.2. 1.2.2 



Figure E.2.5.2.1.2.1.1: CS network originated modification 
from multimedia to speech when the CS leg supports BlCC 

CInange from speecin to multimedia 



Figure E.2.5.2. 1.2.2.1 shows a CS network originated modification from speech to multimedia during an ongoing 
session when the CS leg supports BlCC. The interworking node receives a Modify Codec message that indicates the 
adding of a video media to the ongoing speech session, message 1 . The interworking node accepts the offer and sends a 
corresponding INVITE message to the IM CN subsystem, message 2. The IM CN subsystem acknowledges the INVITE 
adding the video media with a 200 OK, message 3, and acknowledges the codec modification request to the BlCC 
network, message 4. The interworking node may have to update the codecs, messages 7 and 8, after the MONA or 
H.245 in-band negotiation in step 6. 

If the IM CN subsystem does not accept the addition of the video media to the session, the interworking node rejects the 
modify codec request to retain the speech only session. 
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Figure E.2.5.2. 1.2.2.1: CS network originated modification 
from speechi to multimedia when thie CS leg supports BICC 

E.2.5.2.2 Non-SCUDIF case (ISUP or BICC without SCUDIF) 



E.2.5.2.2.1 



Change from multimedia to audio 



Figure E.2.5.2. 2. 1.1 shows an IM CN subsystem originated modification from multimedia to audio during an ongoing 
session when the CS leg supports ISUP or BICC without SCUDIF. The interworking node receives an INVITE message 
that indicates the dropping of the video media from the session, message 1 . The interworking node can only accept the 
dropping of the media component and acknowledges the INVITE with a 200 OK, message 2. There are three alternative 
ways to handle the issue: 

The video component stays on in the CS leg. The interworking node may use the video component to send an 
announcement to the CS terminal to inform the user about the change of the end-to-end connection to audio only. 
Refer to figure E.2.5.2.2. 1.1. 

The interworking node initiates an H.245 in-band negotiation to close the video channel. 

The interworking node terminates the session. 
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Figure E.2.5.2.2. 1.1: IM CN subsystem originated modification 
from multimedia to speech when the CS leg supports ISUP or BICC without SCUDIF 
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E.2.5.2.2.2 



Change from speech to multimedia 



Figure E.2.5.2.2.2. 1 shows an IM CN subsystem originated attempt to change from speech to multimedia during an 
ongoing session when the CS leg supports ISUP or BICC without SCUDIF. The interworking node receives an INVITE 
message that offers the adding of a video media to the ongoing speech session, message 1 . The interworking node turns 
down the offer and responds to the INVITE message with the speech codec in the 200 OK message to retain the speech 
only session, message 2. 
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Figure E.2.5.2.2.2. 1 : IM CN subsystem originated modification 
from speech) to multimedia when the CS leg supports ISUP or BICC without SCUDIF 

E.2.6 Call release 

E.2.6.1 Call release initiated from the IM CN subsystem side 

When the MGCF has received a BYE message (signal 1 in figure E.2.6. 1.1) from the IM CN subsystem side, the MGCP 
may end the H.245 session between the IM-MGW and the CS network side (signal 3 in figure E.2.6. 1.1) firstly. 

NOTE: A call release using only ISUP/BICC signalling at the CS side proceeds faster. H.324 terminals can 

handle situations where they do not receive H.245 call release signalling (see subclause 7.5.2 of ITU-T 
Recommendation H.324 [81]), and this scenario also occurs e.g. at loss of coverage or when a node 
transporting H.223 transparently releases the call. 

The procedure of ending the H.245 session is defined in the subclause E.4. After receiving the BYE message, the 
MGCF shall also send a 200 OK [BYE] message (signal 2 in figure E.2.6. 1.1) towards the IM CN subsystem. 

After ending the H.245 session, the MGCF shall send a REL message (signal 4 in figure E.2.6. 1.1) to the succeeding 
node. If the IM CN subsystem interworks with ISUP based CS network, the interworking node shall release the 
resources for the IMS side and the CS network side (signal 6 in figure E.2.6. 1.1) after sending the REL message. If the 
IM CN subsystem interworks with BICC based CS network, the interworking node shall release the resources for the 
IMS side and the CS network side (signal 6 in figure E.2.6. 1.1) upon receiving the RLC message (signal 5 in 
figure E.2.6. 1.1) from the CS network side. The procedures of releasing the resources for the IMS side and the CS 
network side are specified in the present TS in clause 7. 

Figure E.2.6. 1.1 shows the message sequence chart for the multimedia call release initiated from the IM CN subsystem 
side. 
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NOTE: Signal 7 is omitted when IM CN subsystem interworks with BICC based CS network and Signal 5 is 
omitted when IM CN subsystem interworks with ISUP based CS network. 

Figure E.2.6.1.1 : Call release initiated from the IM CN subsystem side 

E.2.6.2 Call release initiated from the CS network side 

If the CS network side initiates the call release, it possibly ends the H.245 session with explicit signalling (signal 1 in 
figure E.2.6.2. 1). The CS network side sends a REL message (signal 2 in figure E.2.6.2. 1) towards the IM CN 
subsystem. The procedure of ending the H.245 session is defined in the subclause E.4. 

When the MGCF receives a REL message (signal 2 in figure E.2.6.2. 1) from the preceding node, the MGCF sends a 
BYE message (signal 3 in figure E.2.6.2. 1) to the IM CN subsystem. After receiving the REL message, the 
interworking node also releases the resources for the IMS side and the CS network side (signal 4 in figure E.2.6.2. 1). 
The procedure of the releasing the resources for the IMS side and the CS network side are specified in the present TS in 
clause 7. After completion of resource release, the MGCF sends a RLC message (signal 5 in figure E.2.6.2. 1) towards 
the preceding node. Figure E.2.6.2. 1 shows the message sequence chart for the multimedia call release initiated from 
the CS network side. 
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Figure E.2.6.2.1 : Call release initiated from the CS network side 

E.2.6.3 Call release initiated from the interworking node 

The interworking node may end the H.245 session between the IM-MGW and the CS network side (signal 1 in 
figure E.2.6.3. 1) firstly. The procedure of ending the H.245 session is defined in the subclause E.4. 

NOTE: A Call Release using only SIP and ISUP/BICC signalling may proceed faster. H.324 terminals can handle 
situations where they do not receive H.245 call release signalling (see subclause 7.5.2 of ITU-T 
Recommendation H.324 [81]), and this scenario also occurs e.g. at loss of coverage or when a node 
transporting H.223 transparently releases the call. 

To release the call, the MGCF shall send a REL message (signal 2 in figure E.2.6.3. 1) to the succeeding node on the CS 
network side. The MGCF shall also send a BYE message (signal 3 in figure E.2.6.3. 1) to the IM CN subsystem side. 

If the IM CN subsystem interworks with ISUP based CS network, the interworking node shall release the resources for 
the IMS side and the CS network side (signal 5 in figure E.2.6.3. 1) after sending the REL message. If the IM CN 
subsystem interworks with BICC based CS network, the interworking node shall release the resources for the IMS side 
and the CS network side upon receiving the RLC message (signal 4 in figure E.2.6.3.1) from the CS network side. The 
procedures of releasing the resources for the IMS side and the CS network side are specified in the present TS in clause 
7. Figure E.2.6.3.1 shows the message sequence chart for the multimedia call release initiated from the interworking 
node. 
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IMS 


Interworking node 
(MGCF+ IM-MGW) 


CS Network 
















1 1 . H.245 Signalling to end the H.245 session 
! between the IM-MGW and the CS network side 






2. BICC or ISUP: REL 




3. SIP: BYE 


4. BICC: RLC 
















5. Release the resources for the IMS side 
and the CS network side 




7. SIP: 200 OK [BYE] 


6. ISUP: RLC 















NOTE: Signal 6 is omitted when IM CN subsystem interworks with BICC based CS network and Signal 4 is 
omitted when IM CN subsystem interworks with ISUP based CS network. 

Figure E.2.6.3.1 : Call release initiated from the interworking node 



E.3 User plane interworking 

E.3.1 Functionalities required in the IM-MGW for multimedia calls 
support 

To enable a multimedia Interworking, the IM-MGW needs to support the reframing of the H.263 video codec and the 
AMR audio codec between CS transport and PS transport as a minimum. The IM-MGW may also support the reframing 
of other codecs and the transcoding of audio and/or video codecs. 

At the CS side, the IM-MGW needs to terminate the H.223 protocol and multiplex / de-multiplex audio, video and 
H.245 signalling. How H.245 related information (e.g. H.245 messages or extracted information) is communicated 
between the MGCF and the IM-MGW is described in Subclause E.4. 



E.4 MGCF and IM-MGW interactions 



E.4.1 Introduction 

This subclause describes requirements for extensions to the Mn interface protocol in 3GPP TS 29.332 [15] needed to 
support the Interworking of multimedia calls. ITU-T Recommendation H.248.1 [2] is used at the Mn interface. 

The H.245 signalling shall be handled by the MGCF. Upon reception of the H.245 messages from the CS side at the 
IM-MGW, the IM-MGW shall forward those H.245 messages as binary data within H.248 messages over the Mn 
interface towards the MGCF. Upon reception of encapsulated binary H.245 messages within H.248 messages, the IM- 
MGW shall forward those H.245 messages towards the CS side. 
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NOTE: Procedures to support MONA (see Annex K of ITU-T Recommendation H.324 [81]) over the Mn 

interface are not defined in the present Release. Furthermore, the signalling flows in subclause E.2 may 
not show MONA related signalling in sufficient detail for MONA related Mn interface interactions. 

E.4.2 Mn signalling interactions 
E.4.2.1 Introduction 

The following subclauses describe the Mn interface procedures triggered by H.245 signalling received in the IM-MGW 
and SIP and RTCP and BlCC or ISUP signalling received in the MGCF. 

All message sequence charts in these subclauses are examples. 

E.4.2.2 H.248 Context IVIodel 

The H.248 context model depicted in figure E.4.2.2. 1 shall be applied for Multimedia Interworking. 



CS-Domain 




Termination: 

Tl CS-Domain (CS-Bearer (BS30) for H.245 control, Speech, Video) 

T2 Multiplexing (H.245 control. Speech, Video) 

T3 Video (own RTP-stream) + Speech (own RTP-stream) 

Stream: 

Streaml (between Tl and T2) data (H.245 control, speech. Video) 

Stream2 (between T2 and T3) Video 

Stream3 (between T2 and T3) Speech 



Figure E.4.2.2. 1 : H.248 Context Model for Multimedia Interworking 

E.4.2.3 Transport of H.245 messages between the MGCF and IM-MGW 



E.4.2.3.1 



General 



H.245 messages shall be transported between the IM-MGW and MGCF over the Mn interface using H.248 Events 
(from the IM-MGW towards the MGCF) and H.248 Signals (from the MGCF towards the IM-MGW). The 
Events/Signals shall contain the following information: 

H.245 message (binary). 
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E.4.2.3.2 Transport from MGCF to IM-MGW 



IMMGW 



3. send H.245 message XXXX in H.223 strearr 



1. H.248 MOD.req 

[C=C1J=TZ 
signal=H245msgout 

{h245mc=XXXX} 



MGCF 



2. H.248 MOD.resp 



Signal 

H245 

Message 



Figure E.4.2.3.2. 1: IVIn signalling interactions for sending H.245 message 

In Signal 1, the MGCF requests the IM-MGW to send an H.245 message to the CS side. To request the IM-MGW to 
send a H.245 message to the CS side, the MGCF shall sent an H.248 signal to the IM-MGW with the complete H.245 
message content. 

NOTE: In order for this command to succeed, Termination T1 towards the CS side needs to be configured. If a 

sending of an H.245 message and a removal of termination T1 is desired, the MGCF needs to apply signal 
1 before removing T1. 
Upon reception of this signal, the IM-MGW shall send the encapsulated H.245 message within the H.248 signal, 
through the H.245 control channel to the CS side (signal 3). 

E.4.2.3.3 Transport from IM-MGW to MGCF 



IM MGW 



3. receive H.245 message XXXX in H.223 

■- ► 



1 H.248 ADD. reg 
[C=C1J=?... ,Event=H245msgin] 



2. H.248 ADD. reap 



H.248 : Notify.req 
[C=C1J=T2' 

Event=H245msgin 
{h245mc=XXXX)l 



5. H.248 : Notify, reap 



MGCF 



Add 

Multiplex 

Termination 



Notify 
H245 

Message 



Figure E.4.2.3.3. 1: Mn signalling interactions for receiving H.245 message 

In signal 1, the MGCF requests the IM-MGW to detect received H.245 message from the CS side and forward them to 
the MGCF. To request the IM-MGW to detect and forward a H.245 message to the CS side, the MGCF shall send a 
suitable H.248 event to the IM-MGW. The event may be indicated through an H.248 ADD command. 

In signal 3, the IM-MGW receives an H.245 message from the CS side. Upon reception of an H.245 message from the 
CS side, the IM-MGW shall de-multiplex the H.245 message from the H.223 stream and forward the H.245 message to 
the MGCF within an H.248 Notify command (signal 4). 

E.4.2.4 Call establishment procedure 

The following information shall be provided from the MGCF towards the IM-MGW: 
Properties to start H.223 Negotiation. 

Request for events for Notification of H.245 message received by the IM-MGW. 
Signals to provide H.245 messages that the IM-MGW shall send towards the CS side. 
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Properties to provide incoming and outgoing H.223 multiplex table. 
Properties to provide H.223 logical channel parameters. 
Property to provide remote H.223 capabilities. 
The Highest Multiplexing Level shall be predefined in the IM-MGW. 
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5. Bearer Establishment 



H.223: Multiplexing Level Negotiation 

[level =i] 



[AMR 
Master 



1. H.248 :ADD.req 
[C=?, T=?, stream=1] 



2. H.248 : ADD.resp 
[C=C1,1=T1] 



3. H.248 : ADD.req 

[C=C1, T=?, stream=2{Codec=H.263}, 

stream=3{Codec=AMR^ 



4. H.248 : ADD.resp 
[C=C1,J=T3i 



6. H.248 : ADD.req 

[C=C1,T=?, Mux=H223,T1, 

LocalControl{ muxlv=2} 

Event=H245msgin ] 



7. H.248 : ADD.resp 
[C=C1,J=T2] 



9. H.245: Terminal Capability Set, 



MP4V-ES,H263[ 
Slave Determination 



10. H.245: Terminal Capability Set Ack, 
Master-Slave Determination Ack 



1 1 . H.245: Terminal Capabilitv Set, 

[H.261,H.263,AMR[ 

Master-Slave Determination 



12. H.245: Terminal Capability Set Ack, Master-Slave Determination Ack 



-I- 
13. H.245: Open Logical Channel 

[H245 logical Channel = LC1\ 



-t- 
14. H.245: Open Logical Channel Ack 

15. H.245: 6pen Logical Channel 



[H245 logical Channel ■■ 



LC2[ 



16. H.245: Open Logical Channel Ack 



1 7. H.245: Multiplex Entry Send 



1 8. H.245: Multipex Entry Send Ack 



19. H.245: Multipex Entry Send 



-t- 
20. H.245: Multiplex Entry Send Ack 



21. H.248 : MOD.req 

[C=C1,J=T2, 

Stream=1{LocalCont{h223capr,muxtblJn,muxtbLout}} 

stream=2{LCN=Z.C/, Co6ec=H263} 

stream=3{LCN=Z.Ci', Codec=AMRJl 



22. H.248 : MOD.resp 



23. H.248 : MOD.req 
[C=C/, T=3, stream=2{Codec=/yi'6'Ji;, 

stream=3{Codec=AMR] 

24. H.248 : MOD.resp 
[C=C/,T=7"J| 



Prepare Bearer or 
Establish Bearer or 
Reserve TDM Circuit 

Reserve IMS 
Connection Point or 
Reserve IMS 
Connection Point 
and Configure 
Remote Resources 



Add 

Multiplex 

Termination 



Configure 

Multiplex 

Termination 



Configure IMS 
Ressources 



NOTE 1 : All H.245 messages (from Signal 9 to Signal 18) are transported through the IM-MGW between the MGCF 

and the CS side, using the procedures described in subclause E.4.2.3 
NOTE 2: Signals 21 and 22 are omitted if the same codec information has already been provisioned in signal 3. 

Figure E.4.2.4.1 : Mn signalling interactions for H.245 termination at the MGCF 

The MGCF shall request terminations towards the CS network (Signal 1 and 2) and towards the IMS (Signal 3 and 4). 
For the terminations towards the IMS, the MGCF provides an estimate about the applicable codecs in the required 
information elements "Local IMS Resources" (for both "Reserve IMS Connection Point" procedure and "Reserve IMS 
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Connection Point and Configure Remote Resources" procedure) and possibly "Remote IMS Resources" (only for 
"Reserve IMS Connection Point and Configure Remote Resources" procedure). 

The MGCF shall request that the H.223 stream is (de-)multiplexed at the MUX termination T2, and that the H.245 
control in H.223 Logical channel is separated (signal 6). Furthermore, the MGCF shall request that the H.223 
negotiation is started, and shall request to be notified about all H.245 messages received by the IM-MGW. 

The IM-MGW shall start the H.223 Multiplexing Level Negotiation after receipt of the corresponding request from the 
MGCF and CS bearer establishment (Signal 8). 

Upon reception of a H.245 Terminal Capability Set message (Signal 9), the MGCF sends a H.245 Acknowledgment 
message (Signal 10). 

The MGCF shall know the H.324 related capabilities of the IM-MGW before starting the H.245 capability negotiation 
with the CS side, e.g. through configuration. The H.245 Terminal Capability Set message send by the MGCF (Signal 
11) should include the codecs which are supported by both the IMS side and the IM-MGW, and the codecs which could 
be transcoded by the IM-MGW from the codecs supported by the IMS side. 

The MGCF may defer sending the Terminal Capability Set message (Signal 1 1) for some time to wait for codec 
information from the CS peer's Terminal Capability Set message and perform a possible IMS-side codec re-negotiation. 
To avoid blocking situations, the MGCF shall not defer sending the signal for an excessive period of time. 

To avoid the CS side selecting the codecs that need to be transcoded at the IM-MGW, the MGCF should aim to be the 
master in the H.245 master-slave determination procedure (Signals 9 to 12). The MGCF shall set the Terminal Type 
parameter as a number larger than 128 in the H.245 Master Slave Determination message. The H.245 master-slave 
determination procedure could be combined with the messages used for the H.245 capability exchange. 

The codecs contained both in the sent and received terminal capability set message may be selected at the CS side. The 
final decision of the selected codecs at the CS side is taken with the H.245 open logical channel procedure (Signals 13 
to 16). 

After the completion of the H.245 multiplex table exchange procedure (Signals 17 to 20), the MGCF shall configure the 
multiplexing termination T2 by indicating to the IM-MGW the contents of the incoming and outgoing multiplex tables 
(Signal 21). 

If codec information needs to be changed compared to what has been provisioned in signal 3, the MGCF shall also 
configure T3 with the appropriate video and/or speech codec(s) (signal 23). 

The call is in the active state. 

E.4.2.5 Handling of H.245 indication message 
E.4. 2.5.1 Overview 

The MGCF shall support the following H.245 indication messages: Function Not Understood Indication / Function Not 
Supported Indication, Jitter Indication. The MGCF may support the H.245 User Input Indication message. All these 
H.245 messages are conveyed between the MGCF and the CS side through the IM-MGW, as described in subclause 
E.4.2.3. 

E.4.2.5. 2 Function Not Understood / Function Not Supported message 

This indication message is used to return requests, responses and commands that are not understood back to the 
transmitter. 

If the MGCF receives a Function Not Understood or Function Not Supported message from the CS side, the MGCF 
may choose to attempt simpler H.245 interaction than the previous H.245 interaction that caused this indication. If this 
is not possible, the MGCF may release the call. 

If the MGCF receives a H.245 request, response or command that can not be understood, the MGCF shall send H.245 
Function Not Supported indication message to the CS side. 
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E.4.2.5.3 User Input Indication message 

The User-Input-Indication message is used e.g. to transport the in-band DTMF information in the H.324 system. 

The MGCF and IM-MGW may support transporting the DTMF information both from the CS side to the IMS side, and 
from the IMS side to the CS side. 

Upon Receipt of a H.245 User-Input-Indication message, the MGCF may apply the procedures in subclause 9.2.8.3 to 
request the IM-MGW to send corresponding RTP telephone-event(s) towards the IMS side. 

Upon receipt of RTP telephone events from the IMS, the MGCF will be notified by the IM-MGW using the procedures 
in subclause 9.2.8.1, if the MGCF has previously configured the IM-MGW as also described in this subclause. Upon 
receipt of the notification, the MGCF may send a H.245 User-Input-Indication message to the CS side. 

E.4.2.6 Handling of H.245 Command message 
E.4. 2.6.1 Overview 

The MGCF shall support the End Session command message. The MGCF may support the Flow Control command 
message and the videoFastUpdatePicture message. All these H.245 messages are conveyed between the MGCF and the 
CS side by the IM-MGW, as described in subclause E.4.2.3. 

E.4.2.6. 2 Flow control command 

The flow control command is used to restrict the upper limit of bit rate of either a single logical channel or the whole 
multiplex stream. The MGCF may support the flow control command received from the CS side. 

NOTE: It is very unlikely that the MGCF will receive a Flow control command, as the capability of controlling 

the video bit rate during a video call was neither implemented nor tested for UEs offering 3G-324M since 
R99, due to the lack of such a necessity in WCDMA where a fixed 64 kbps bearer is maintained to 
continuously transport 3G-324M PDUs. 
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IM^Q/V 




MKF 
























Call In Active State 






1 . H.245: Flow Control Command 








C= 


2.H.248: Modifv.req 
C1,T=T2,stream{LCN}, stream mode=Recieve Only 








3.H.248: Modify.rsp 








4. H.245; Close Logical Channel{Old LCN} 

Open Logical Channel {New LCN} 








5. H.245: Close Logical Channel ACK {Old LCN) 

Open Logical Channel ACK{New LCN} ^ 






c 


=C1,T 


6.H.248: Modify.req 
=T2,stream{New LCN, codec}, stream mode = sendrecei\ e 




7.H.248: Modify.rsp 






8. H.245: Flow Control indication 








^- 


11.H.248: Modify.req 
C=C1 ,T=T3,stream{codec} 


9.SIP:relNVITE 
10.SIP:200OK 




12.H.248: Modify.rsp 












n 





Figure E.4.2.6.2.1 : Mn procedure of Flow control command 

In Signal 1, the MGCF receives the Flow Control Command from the CS side. 

If the minimum bitrate of the current codec is larger than the bitrate requested by the H.245 Flow Control Command 
message, the MGCF indicates the IM-MGW to stop the transmission of the media stream over the logical channel 
(signal 2). Then the MGCF may select another codec that can satisfy the requested bitrate limit. In signal 4, the MGCF 
closes the old logical channel and opens a new logical channel with new codec to satisfy the bitrate limit in the CS side. 
In signal 6, the MGCF indicates the IM-MGW to modify the LCN, codec and stream mode of the multiplexing 
termination. In signal 8, the MGCF sends flow control indication message to CS side with the current maximum bitrate. 
If the MGCF chooses to change the CS-side codec, the MGCF may also adjust the codec at the IMS side accordingly. 
To do so, the MGCF may need to re-negotiate the codec at the IMS side using a SIP re-INVITE message (signals 9 and 
10). In addition, the MGCF may modify the codec of IMS termination accordingly (signal 11). 

The MGCF may also apply interworking procedure towards RTCP at the IMS side as described in subclause E.4.2.8 
when receiving a H.245 Flow Control Command. 

E.4.2.6.3 End Session Command 

The end session command is used to close the H.245 control channel after all the logical channels have been closed. 

The MGCF may send an end session command to the CS side through the IM-MGW to release a call. 

If the MGCF receives an end session command from the CS side, it shall release the call if the call is in the active state. 

E.4. 2.6.4 videoFastUpdatePicture 

The MGCF may apply interworking procedure towards RTCP as described in subclause E.4.2.8 when receiving a H.245 
videoFastUpdatePicture message. The MGCF may also be triggered by the procedures in subclause E.4.2.8 to send a 
H.245 videoFastUpdatePicture message. 
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When receiving frequent H.245 videoFastUpdatePicture messages for a SCUDIF call (see 3GPP TS 23.172 [121]), an 
MGCP should initiate a service-change from multimedia to speech and remove the IMS MTSI video component with 
SIP/SDP signalling. When receiving frequent H.245 videoFastUpdatePicture messages for a non-SCUDIF call, an 
MGCF should disable the CS video and remove the IMS MTSI video component with SIP/SDP signalling. 

NOTE: In a congestion situation at the IMS side, frequent packet losses might occur and dropping the video 

component may serve as a counter-measure to reduce the packet loss frequency. However, CS terminals 
might not be able to initiate such a switch-over to voice, but might rather react with repeated H.245 
videoFastUpdatePicture message. 

E.4.2.7 Mn Signalling Interactions to support the Media Oriented Negotiation 
Acceleration (MONA) 

E.4.2.7. 1 Overview 

Media Oriented Negotiation Acceleration (MONA), as specified in ITU-T H.324[81] provides simplified procedures 
that allow for a faster call set-up of a H.324 Multimedia call than standard H.324 procedures, and also allow for a 
fallback to standard H.324 procedures if either party does not support the enhanced procedures. 

The support of MONA is optional for an IM-MGW and MGCF supporting multimedia interworking, as no call failure 
but only a fallback to standard H.324 setup procedures will occur if the procedures are not supported. 

MONA "preference message" signalling is used instead of H.324 Multiplexing level negotiation. Should standard H.324 
Multiplexing level stuffing flags be received, a fallback to standard H.324 procedures is triggered. The sending of 
MONA preference messages is repeated by each MONA capable H.324 terminal until a reception is acknowledged by 
the peer. During this phase, two PDU types may optionally be attached by MONA terminals to these preference 

messages: 

Media Preconfigured Channel (MPC) PDUs: MONA defines a small number of preconfigured H.223 channels 
for the most widespread audio and video codecs (AMR, AMR-WB, H.264 MPEG4 and H.263). Media PDUs for 
these codecs may be attached to the MONA "preference message" during the call setup. 

Signalling Preconfigured Channel (SPC) PDUs: These PDUs are H.245 generic request messages with special 
parameters defined by MONA. These PDUs may also be attached to MONA preference messages. 

According to MONA, each MONA capable terminal shall support at least one of these PDU types. The MONA 
capability of the IM-MGW can be audited by the MGCF. 

The MONA preference message exchange in combination with attached MPC or SPC PDUs may result in the 
establishment of the desired media channels without further H.245 signalling. Otherwise, H.245 will be used after the 
MONA preference message exchange is acknowledged to negotiate media channels, but MONA defines some 
accelerated H.245 procedures (ACP) to speed up these H.245 procedures. 

The design of Mn procedures to support MONA is guided by the following considerations: 

The H.245 handling should be performed in the MGCF to keep procedures aligned as far as possible with 
standard Mn procedures to support H.324 interworking. 

The MGCF should also control MONA preference message exchange procedures in order to maintain the agreed 
architectural work split between MGCF and IM-MGW in analogy to the H.245 handling. 

However, the IM-MGW needs to understand the MONA preference messages at least to a sufficient degree to 
de-encapsulate the possibly attached MPC and SBC PDUs. 

Furthermore, the frequent retransmissions of MONA preference messages required by MONA procedures are to 
be performed by the IM-MGW autonomously to avoid unnecessary load at the Mn interface and the MGCF. 

Furthermore, for resource reservation at the IM-MGW, it is assumed that the IM-MGW has knowledge about 
supported predefined Media Preconfigured Channel configurations as specified in subclause K.9.2 of H.324 [81] 
in order to limit the amount of information transferred in the Mn interface when establishing MPC channels. The 
offered channel resources are reserved by the IM-MGW. 
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In order to avoid increasing call establishment time when interworking with legacy terminals and at the same 
time avoid unnecessary load at the Mn interface, the MGCF may initiate both MONA and legacy H.245 
procedures simultaneously in parallel. The MGCF shall in this case arm a legacy detection event with an 
embedded signal descriptor including the initial legacy H.245 message. The IM-MGW will only send the signal 
in case a fallback condition to legacy is detected. 

Editor"s note: It is FFS whether the mux-level-indication event can be used as a legacy detection event, and whether 
it is more feasible than the mechanism for legacy detection described. 
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E.4.2.7.2 Mn Interactions for MONA preference messages 



5. Bearer Establishment 



. MONA preferences 

[aok=00] 



. MONA preferences 

[aok=00] 



9. MONA preferences 

[ack=00] 



10. MONA preferences 

[aok=01] 



9. MONA preferences 

[aok=00] 



10. MONA preferences 

[aok=011 



1.hL248: ADD.req 
[C=?, T=?, stream = 1] 



2. hL24§.: ADD.resp 
[C=Cr,T=r7] 



3. H.248 : ADD.req 

[C=C>, T=?, stream=2{Codec=H.263), 

stream=3{Codec=AMR;] 



4. tL24§.: ADD.resp 
[C=Cr,T=r31 



_: ADD.req 
Mux=H223,T1, 



6. H.248 

[C=C1,T= 

LocalControl{MONA preferences, muxlv=2} 

Event=legacyDeteoted(h245msgout[octet string]), 

MONA-preference-reception, MONA-preference- 

completed, H245msgin, 

[MPC-reception, SBC-reception] ] 



7. hL24§.: ADD.resp 
lC=Cr, 7=727 



11. H.248 : Notify. req 
IC=C1J=T2' 

Event=MONA-preference-receptiom 
(MONA preferences}] 



12. H.248 : Notify. resp 



Prepare Bearer or 
Estabiish Bearer or 
Reserve 7Dlyl Circuit 

Reserve IMS 
Connection Point or 
Reserve IIVIS 
Connection Point 
and Configure 
Remote Resources 



Add 

Multiplex 

7ermination 



Notify 

MONA 

prefrence 

reception 



13. MONA preferences 

[ack=01] 



14. MONA preferences 

[ack=10] 



13. MONA preferences 

[ack=01] 



14. MONA preferences 

[ack=10] 



Optiortal Procedures for reception of SPC PDU, sending of SPC PDU, reception of MPC 
PDU, sending of MPG PDU 



15. MONA preferences 

[ack=10] 



16. H.248 : Notify. req 
\C=C1.1=T2' 
Event=MONA-preference-completed] 



17. H.248 : Notify. resp 



Notify 

MONA 

prefrence 

completed 



1 8. Acceierated H.245 cali setup procedures 



19. H.248 : MOD. req 

[C=C7,7=72, 

Stream=1{LocalCont{ti223oapr,muxtblJn,muxtbl_out)) 

stream=2{LCN=/.Cr, Co6ec=H263l 

stream=3{LCN=LC2, Codec=AMR)] 



20. H.248 : MOD. resp 



21. H.248 : MOD. req 
IC=C1, 7=3, stream=2{Codeo=H263;, 

stream=3{Codec=AMR] 

22. H.248 : MOD. resp 
[C=C7,7=73] 



Configure 

Multiplex 

7ermination 



Configure IMS 
Ressources 



NOTE 1 : 



NOTE 2: 



MONA preference messages are repeated several times. One repetition is shown for eacti such message, 

with the same signal number as the first message. 

The Context model in figure E. 4. 2. 2.1 is assumed in this call flow. 

Figure E.4.2.7.2. 1 : Mn signalling interactions for MONA preference messages 



The MGCF shall request terminations towards the CS network (Signal 1 and 2) and towards the IMS (Signal 3 and 4). 
For the terminations towards the IMS, the MGCF provides an estimate about the applicable codecs in the required 
information elements "Local IMS Resources" (for both "Reserve IMS Connection Point" procedure and "Reserve IMS 
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Connection Point and Configure Remote Resources" procedure) and possibly "Remote IMS Resources" (only for 
"Reserve IMS Connection Point and Configure Remote Resources" procedure). 

The MGCF shall request that the H.223 stream is (de-)multiplexed at the MUX termination T2 (signal 6). Furthermore, 
the MGCF shall request that MONA preferences negotiation is started, and shall provision the MONA preferences to be 
indicated by the IM-MGW. The MGCF shall encode the MONA preferences as described in subclause K.6 of ITU-T 
H.324 [81]. The MGCF shall take the H.324 related capabiHties of the IM-MGW into account in the MONA 
preferences. The MGCF can know these capabilities by configuration. The IM-MGW will only support symmetric 
codec usage. If several codec alternatives are offered for MPC, it is the responsibility of the MGCF to ensure that 
symmetric codecs are established by not selecting transmit codec until the receive channel has been opened by MPC 
media. The MGCF shall also request to be notified about the reception of the remote MONA preferences and about the 
completion of the MONA preference exchange, or an H.245 message on the H.223 control channel. The MGCF may 
also initiate standard H.245 signalling in parallel in order to minimize the time for a legacy interworking fallback. This 
is done by arming a legacy detection event including an embedded signal descriptor. The embedded signal is the initial 
H.245 message out signal (including H.245 TCSh-MSD) to send in case fallback to legacy interworking is detected. The 
IM-MGW will only send the embedded signal in case it detects H.223 related indications of a legacy interworking as 
specified in subclause K.7.1.2 in H.324 [81]. Upon receiving the legacy detected event, the MGCF continues with 
standard H.245 call setup procedures waiting for the reception of a remote H.245 TCS as well as acknowledgements on 
the sent H.245 TCSh-MSD. If the MGCF indicates the capability to receive SPC PDUs within the MONA preferences, it 
shall also request to be notified about incoming SPC PDUs, as detailed in subclause E.4.2.7.4. If the MGCF indicates 
the capability to receive any MPC PDUs within the MONA preferences, it shall also request to be notified about 
incoming MPC PDUs, as detailed in subclause E.4.2.7.3. 

The IM-MGW shall start sending MONA preference messages after receipt of the corresponding request from the 
MGCF and CS bearer establishment (Signal 8). The IM-MGW shall repeat sending those messages and increment the 
acknowledgment bits of sent MONA preference messages when receiving incoming MONA preference messages 
according to MONA procedures (signals 8, 10, 14). 

After sending at least 10 MONA preference messages, while the IM-MGW continues to send and receive MONA 
preference messages, it shall attach MPC or SPC PDUs if requested to do so by the MGCF as described in subclauses 
E.4.2.7.3 and E.4.2.7.4, respectively. If the IM-MGW receives preference messages with an attachment, it shall inspect 
the first octet of that attachment that will contain a MUX code according to table K.15 of ITU-T H.324 [81] that 
identifies the attached PDU as either a MPC PDU of one of the predefined channels or a SPC PDU. The IM-MGW shall 
handle the attached MPC or SPC PDUs as described in subclause E.4.2.7.3 and E.4.2.7.4, respectively. 

After sending at least 10 MONA preference messages, the IM-MGW should insert stuffing flags indicating the 
multiplexing level received from the MGCF between MONA preference messages as described in subclause K.7.1.1 of 
ITU-T H.324 [81]. 

The IM-MGW shall notify the MGCF when receiving the first incoming MONA preference message (Signals 1 1 and 
12) and forward the received information. Subsequent incoming MONA preference message will be identical apart 
from possible increments in the acknowledgement bits. The IM-MGW shall not notify the MGCF about these messages. 
Upon reception of the notification of a MONA preference message, the MGCF shall compare the received MONA 
preferences message with the preferences message it sent and react as described in subclause 7.1 of ITU-T H.324 [81]. 

When receiving an incoming MONA preference message with acknowledgment bits 10 or receiving the first non-empty 
H.223 MUX PDU, the IM-MGW shall notify the MGCF about the completion of the MONA preference exchange 
procedure (signals 16 and 17). The notification shall be only triggered by the one of the two events which occurs first. If 
the IM-MGW is not configured to send and detect SPCs, the IM-MGW shall then stop sending MONA preference 
messages and, if a MONA preference message with acknowledgment bits 10 has been received, it shall also stop 
receiving MONA preference messages. If the IM-MGW is configured to send and detect SPCs, the IM-MGW shall 
continue sending and receiving MONA Preference messages encapsulating the SPC/MOS messages until the MGCF 
configures the IM-MGW stop sending and detecting SPCs. 

NOTE: In the unlikely case that a first non-empty H.223 MUX-PDU is received before the first MONA 

Preference Message has been received, the IM-MGW will continue the detection of incoming MONA 
Preference Messages and will apply the Notify-MONA-preference-Reception-procedure after the Notify- 
MONA-preference-completed procedure. 

After receiving the notification about the completion of the MONA preference exchange procedure, and a completion of 
the possible subsequent accelerated H.245 setup procedures, the MGCF shall configure the multiplexing termination T2 
by indicating to the IM-MGW the contents of the incoming and outgoing multiplex tables (Signal 19), and may modify 
the selected codecs at both the MUX and the IMS side (signal 21). 



£75/ 



3GPP TS 29.163 version 9.13.0 Release 9 



268 



ETSI TS 129 163 V9.13.0 (2013-04) 



E.4.2.7.3 Mn Interactions for MONA MPCs 
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6 H.248 : Notify.req 
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Mux Code 




Notify 




PDU in MPC 
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7 H.248 : Notify.resp 

8. H.248: MOD.req 

C=C1, J=T2, 

Stream=1{LocalCont{,muxtbl_out}}] 




prefrence 
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Configure 






9. H.248: MOD.resD 




Multiplex 
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11. 




13. H.248 : Notify.req 
[C=C^,T=T2 ' 
Event=MPCin 
{muxcode=Mux Code}] 






12. 


MONA preference messaqe, 
Mux Code, MPC PDU 




Notify 






■■ 






14 H.248: Notify.resp 




MPC 




15. H.248: MOD.req 

IC=C1, J=T2, 

Stream=1{LocalCont{,muxtbl_in}}] 


Configure 






16. H.248: MOD.resD 




Multiplex 
Termination 



NOTE 1 : MONA preference messages are repeated several times. One repetition is sfiown for each sucfi message, 

with the same signal number as the first message. 
NOTE 2: The Context model in figure E. 4. 2. 2.1 is assumed in this call flow. 

Figure E.4.2.7.3. 1 : Mn interactions for IVIONA lUIPCs 

If the MGCF indicates the abihty to receive any predefined MPCs channel types in the MONA preferences messages, 
the MGCF shall request the IM-MGW to report the channel type of received MPC PDUs (Signal 1 in figure E.4.2.7.3. 1, 
Event "MPC Reception"). 

If the MGCF intends to use MPCs for sending media during the MONA setup, the MGCF shall request the IM-MGW to 
send available media encoded according to the media predefined channel types defined by MONA (signal 1 in figure 
E.4.2.7.3. 1, Signal "MPC MUX Code" ) while the MONA preference exchange described in subclause E.4.2.7.2 is 
ongoing. The MGCF should select channel types for codecs which are supported by both the IMS side and the IM- 
MGW, and/or for codecs which could be transcoded by the IM-MGW from the codecs supported by the IMS side. The 
MGCF shall only include one channel type per each desired media type (audio, video) in the "MPC MUX Code" signal. 
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The MGCF may also configure the MGW to receive these channels at the same time by supplying the Incoming 
Multiplex Table IE in the Add Multiplex Termination Procedure. 

Upon reception of this request, the IM-MGW shall forward any media received from the IMS side in MPC PDUs of the 
corresponding predefined channel type attached to MONA preference messages, transcoding the media if required 
(Signal 4). 

According to the procedures in subclause E.4.2.7.2, the IM-MGW will notify the MGCF (signal 6) when receiving the 
first incoming MONA preference message (Signals 5). The MGCF shall then analyse the Media Preconfigured Channel 
Receive bits within the MONA preference message and configure the MGW accordingly: 

- If MPC(s) that the MGCF has previously configured within the "MPC MUX Code" signal are supported 
according to these bits, the MGCF shall configure the IM-MGW to send these MPC using the predefined 
channels (signal 10) by supplying the corresponding Outgoing Multiplex Table in the Configure Multiplex 
Termination procedure (signal 8). 

- If some of the MPC(s) that the MGCF has previously configured within the "MPC MUX Code" signal are not 
supported according to these bits, the MGCF shall configure the IM-MGW to terminate the media on those 
MPC(s) by modifying the MPC Mux Code signal using the Configure Multiplex Termination procedure. In 
addition, the MGCF may configure the IM-MGW to send media on other supported MPC(s) by supplying the 
corresponding Outgoing Multiplex Table in the Configure Multiplex Termination procedure (not shown in figure 
E.4.2.7.3.1). 

- If all of the MPC(s) that the MGCF has previously configured within the "MPC MUX Code" signal are not 
supported according to these bits, the MGCF shall configure the IM-MGW to terminate MPC operations in those 
unsupported channels. The MGCF shall either remove the MPC Mux Code signal using the Stop MPC procedure 
or configure the IM-MGW to send media on other supported MPC(s) by supplying the corresponding Outgoing 
Multiplex Table in the Configure Multiplex Termination procedure (not shown in figure E.4.2.7.3.1). 

When the MGCF provides an Outgoing Multiplex Table, the IM-MGW shall terminate sending any MPC PDUs as 
attachments to MONA preference message. 

Note: Any previously provisioned "MPC MUX Code" signal becomes irrelevant. 

When being notified about the receipt of the first incoming MONA preference message, the MGCF may also analyse 
the Media Preconfigured Channel Receive bits within the MONA preference message and configure the MGW with a 
suitable Incoming Multiplex Table using the Configure Multiplex Termination procedure (not shown in figure 

E.4.2.7.3.1). 

If the IM-MGW receives the first MONA preference message with attached MPC PDU of a given predefined channel 
type (signal 12), or if the IM-MGW receives the first non-empty H.223 MUX PDU of a given predefined channel type 
which has been configured with the Incoming Multiplex Table, and the MGCF has requested a notification about such 
an event, the IM-MGW shall notify the MGCF about the received channel type (signal 13). The IM-MGW shall not 
notify the MGCF about subsequent receptions of MPC PDUs of the same channel type. 

Upon reception of such a notification, if the IM-MGW supports the indicated channel type and has not yet been 
configured to receive media of that channel type, and if the MGCF has previously indicated the capability to receive 
MPCs of that channel type within MONA preference messages, the MGCF shall configure the IM-MGW to receive 
media of that channel type and forward them to the IMS side by supplying the Incoming Multiplex Table IE in the 
Configure Multiplex Termination procedure (Signal 15). 

If the MGCF determines (e.g. after receipt of signal 5 or signal 12) that some desired media channels can not be 
established using the MPC procedures, the MGCF should use accelerated H.245 procedures as defined by MONA to set 
up media channels. Corresponding H.245 messages shall be transported transparently between the IM-MGW and the 
MGCF using the "Signal H.245 message" and "Notify H.245 message" procedures. 

The MGCF can receive a forwarded MONA preference message from the IM-MGW when the MGCF has already 
configured the IM-MGW to send media on an MPC. If the processing of this message in the MGCF leads to the 
conclusion that MPC procedures need to be aborted because SPC preferred (SPP) is determined, the MGCF shall 
configure the IM-MGW to terminate MPC operations by removing the MPC related event MPC-reception and MPC 
Mux Code signal using the Stop MPC procedure. 
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E.4.2.7.4 Mn Interactions for MONA SPCs 



E.4.2.7.4.1 



General 



H.245 PDUs for SPC shall be transported between the IM-MGW and MGCF over the Mn interface using H.248 Events 
(from the IM-MGW towards the MGCF) and H.248 Signals (from the MGCF towards the IM-MGW). The 
Events/Signals shall contain the following information: 

H.245 message (binary). 

The related procedures are distinct from the procedures in subclause E.4.2.3, since the PDUs are received or sent by the 
IM-MGW using the SPC, i.e. as attachment to MONA preference messages. 

If the MGCF supports SPCs, it shall comply with the SPC procedures in subclause K.8 of ITU-T H.324 [81]. The 
repetition of sending the same SPCs will be handled by the IM-MGW. When the MGCF receives an acknowledgement 
from the CS side it shall request the IM-MGW to stop the repetition sending of the SPCs, 

Within the sent SPC PDUs, the MGCF should include the codecs which are supported by both the IMS side and the IM- 
MGW, and the codecs which could be transcoded by the IM-MGW from the codecs supported by the IMS side. 



E.4.2.7.4.2 



Transport from MGCF to IM-MGW 



IM MGW 



send H.245 message XXXX attached to 
I MONA prefrence request 



3. 



send H.245 message XXXX attached to 
MONA prefrence request 



1. H.248 MOD.req 
[C=C1J=TZ 
signal=SPCout 
{h245mc=XXXX} 



2. H.248 MOD.resp 



MGCF 



Signal 
SPC 



NOTE 1 : MONA preference messages are repeated several times. One repetition is shown for each such message, 

with the same signal number as the first message. 
NOTE 2: The Context model in figure E. 4. 2. 2.1 is assumed In this call flow. 

Figure E.4.2.7.4.2. 1 : Mn interactions for sending lUIONA SPCs 

In Signal 1, the MGCF requests the IM-MGW to send an H.245 message to the CS side. To request the IM-MGW to 
send a H.245 message to the CS side, the MGCF shall sent an H.248 signal to the IM-MGW with the complete H.245 
message content. 

Upon reception of this signal, the IM-MGW shall send the encapsulated H.245 message within the H.248 signal, as 
attachment to a MONA preference message as described in subclause K.9.4 of ITU-T H.324 [81] (signal 3). It should 
repeat sending this H.245 message as attachment to subsequent MONA preference messages. 
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E.4.2.7.4.3 



Transport from IM-MGW to MGCF 



IMMGW 



receive H.245 message attached to 
IMONA preference message 



MGCF 



1 H.248 ADD.rea 

[C=C1,J=? ... ,Event=SPC-reception] 



2. H.248 ADD.resD 



H.248 : Notify. req 
■ [C=C1J=T2' 

Event=SPCin 
{h245mc=XXXX}] 



5. H.248 : Notify. resp 



Add 

Multiplex 

Termination 



Notify 
SPC 



NOTE 1 : MONA preference messages are repeated several times. One repetition is sfiown for each such message, 

with the same signal number as the first message. 
NOTE 2: The Context model in figure E. 4. 2. 2.1 is assumed in this call flow. 

Figure E.4.2.7.4.3. 1 : Mn interactions for receiving IVIONA SPCs 

In signal 1, the MGCF requests the IM-MGW to detect received 11.245 message from the CS side in SPC PDUs 
attached to MONA preference messages and forward them to the MGCF. To request the IM-MGW to detect and 
forward these H.245 message, the MGCF shall send a suitable H.248 event to the IM-MGW. The event may be 
indicated through an H.248 ADD command. 

In signal 3, the IM-MGW receives an H.245 message from the CS side attached as SPC PDU to a MONA preference 
message. Upon reception of such an H.245 message from the CS side, the IM-MGW may check, based on bitwise 
comparison of the previously received H.245 message, if it has already forwarded the same H.245 message to the 
MGCF, in which case the IM-MGW may choose not to forward the same H.245 message to the MGCF. Otherwise the 
IM-MGW shall forward the H.245 message to the MGCF within an H.248 Notify command (signal 4). 

NOTE: According to H.324 [81] a MOS request Ack message shall be sent to every received MOS request. If the 
IM-MGW chooses, based on the bitwise comparison, not to forward the received H.245 message to the 
MGCF, no MOS request Ack message will be generated. However, the MGCF will request the IM-MGW 
to automatically retransmit the MOS request Ack message generated by the MGCF itself. 

If the IM-MGW does not support forwarding SPC PDUs or has not been requested by the MGCF to forward these 
PDUs, it shall discard received SPC PDUs. 



E.4.2.7.4.4 



Termination of SPC procedure 





IMMGW 
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4 H.248 IVIOD.req 
[C=C^,T=T2 Remove Signal-SPC+ SPC-r 
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5 H.248 IVIOD.resp 


Stop SPC 
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NOTE 2: The Context model in figure E. 4. 2. 2.1 is assumed in this call flow. 

Figure E.4.2.7.4.4.1 : IVIn interactions for terminating SPC procedure. 
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If the processing of an incoming MONA Preference Message in the MGCF leads to the conclusion that SPC procedures 
need to be aborted as a result of the test of the SPC bits, the MGCF shall configure the IM-MGW to terminate SPC 
operations by removing the SPC related event SPC-reception and SPCout signal using the Stop SPC procedure. In this 
case, H.245 signalling may be started simultaneously. 

If the MGCF determines the completion of the SPC procedures according to subclause K.8 of ITU-T H.324 [81] (based 
on incoming signal 1 in figure E.4. 2. 7.4.4.1), the MGCF shall configure the IM-MGW to stop sending and detecting 
SPCs (signal 4 in figure E.4.2.7.4.4.1). 

E.4.2.7.5 Mn Interactions for fallback from MONA procedures to standard H.324 setup 



5. Bearer Establishmenl 



. MONA preferences 

[aok=00] 



8. MONA preferences 

[aok=00] 



9. Legacy interworking condition 



10. octet string (H.245 TCS+MSD) 



1. H.248 : ADD.req 
[C=?, T=?, stream = 1] 



2. H.248 : ADD. resp 
[C=Cr,T=T7] 



3. hL24§.: ADD.req 

[C=C», T=?, stream=2{Codec=H.263), 

stream=3{Codec=AMR;] 



4. K,24a: ADD.resp 
IC=C1,T=T3] 



6. H.248 : ADD.req 

[C=C1,T=?, Mux=H223,T1, 

LocalControl{MONA preferences, muxlv=2}, 

Event=legacyDetected(h245msgout[octet string]), 

MONA-preference-reception, MONA-preference- 

completed, H245msgin, 

MPC-reception, SBCin ] 



7. tL248: ADD.resp 

[c=cr,T=r2; 



11. H.248 : Notify. req 
IC=C1,T=T2' 

Event=legacy Detected 



12. H.248 : Notify. resp 



Prepare Bearer or 
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Reserve IMS 
Connection Point or 
Reserve IIVIS 
Connection Point 
and Configure 
Remote Resources 



Add 

Multiplex 

Termination 



Notify detection of 
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13. standard H.245 call setup procedures continuation, Figure E.4. 2.4.1 starting with step 9 



NOTE 1 : MONA preference messages are repeated several times. One repetition is shown for each such message, 

with the same signal number as the first message. 
NOTE 2: The Context model in figure E. 4. 2. 2.1 is assumed in this call flow. 

Figure E.4.2.7.5. 1 : Mn signalling interactions for fallback from MONA procedures to standard H.324 

setup 

When the MGCF requests that the MONA preferences negotiation is started, the MGCF may also initiate standard 
H.245 signalling towards the IM-MGW that shall only be sent in case the IM-MGW detects legacy interworking. The 
MGCF arms an event to detect legacy interworking with an embedded signal descriptor including an H.245 message out 
signal. The embedded H.245 signal is the initial H.245 TCS-i-MSD signal to send in case fallback to legacy interworking 
is detected. The MGCF shall also request to be notified about a H.245 message on the H.223 control channel. The 
MGCF shall also provision a multiplexing level which will be advertised by the IM-MGW (Signal 6). 

If the IM-MGW detects a legacy interworking condition (signal 9), it shall stop sending MONA preference messages, 
including those MONA messages used to encapsulate MPC or SPC. The IM-MGW shall engage in normal H.324 
multiplexing level negotiations. In case the MGCF armed a legacy detection event, the embedded H.245 signal shall be 
sent by the IM-MGW (signal 10). The legacy detection event is sent to the MGCF (signal 1 1). 

The MGCF shall upon detection of legacy interworking stop MONA procedures and continue with standard H.245 call 
set up procedures, as depicted in figure E.4.2.4.1 starting with step 9. 

If the IM-MGW receives a normal H.245 message (not depicted), it shall also forward this message to the MGCF. If the 
MGCF receives such a H.245 message during the MONA call setup, and this H.245 message is a normal Terminal 
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Capability Set message, the MGCF shall also stop MONA procedures and continue with standard H.245 call set up 
procedures, as depicted in figure E.4. 2.4.1 starting with step 9. 

To stop MONA related procedures at the IM-MGW, the MGCF shall remove the MONA related signals that were 
active (MONA Preferences, SPCout, MFC Mux Code; note that MONA Preference and SPCout causes the MGW to 
send the MONA Preference message or the contained H.245 message several times) and events 
(MonaPreferenceReception, MonaPreferenceCompleted, SPC-reception and MPC-reception, using the Stop MONA 
Negotiation procedure. 

E.4.2.8 Interworking between RTCP messages and H.245 messages 



E.4.2.8.1 



Overview 



The following subclauses describe the interworking procedures between the RTCP messages listed in table E.4.2.8. 1.1, 
which are used to enhance the quality of the media distribution by MTSI terminals at the IMS side, and the 
corresponding H.245 messages in 3G-324M at the CS side listed in table E.4.2.8. 1.1. 

As the H.245 protocol is terminated at the MGCF and RTCP is received at the IM-MGW, Mn procedures to support the 
transfer of RTCP related information are defined in the following subclauses to support this interworking. 

Table E.4.2.8. 1.1 : RTCP and H.245 messages that may be interworked 



RTCP Messages 


H.245 messages 


Remarks 


Picture Loss Indication (PLI) {[109]) 


VideoFastUpdatePicture 




Temporary IVIaximum IVIedia Stream 
Bit Rate Request (TMMBR) ([110]) 


Flow Control Command/ Flow 
Control Indication 


This interworking procedure is not 

recommended. 

The reception of TMMBR at the IMS side is 

expected to be more frequent than the 

reception of Flow Control Command at the CS 

side. 



NOTE 1 : It is very unlikely that the MGCF will receive a Flow control command, as the capability of controlling 

the video bit rate during a video call was neither implemented nor tested for UEs offering 3G-324M since 
R99, due to the lack of such a necessity in WCDMA where a fixed 64 kbps bearer is maintained to 
continuously transport 3G-324M PDUs. 

NOTE 2: Terminals are expected to support receiving the FlowControlCommand, as this is a mandatory feature in 
subclause 6.4.3 in H.324. But most terminals would not really follow the received 
FlowControlCommand, but rather ignore it. However, for older 3G-324M terminal lock-up or system 
crash was not uncommon during lOTs. Therefore safe handling of this command is not guaranteed 
absolutely 

The interworking shown in table E.4.2.8. 1.1 is only applicable if video is relayed without transcoding. 

If transcoding is applied, the IM-MGW should adopt its transcoder accordingly if receiving the RTCP messages listed 
in table E.4.2.8. 1.1, and the MGCF should configure the transcoder in the IM-MGW accordingly if it receives the H.245 
messages in table E.4.2.8. 1.1. 

For an MGCF and IM-MGW that support video interworking as specified in the present Annex E, the support of the 
procedures in the present subclause E.4.2.8. 2 and E.4.2.8. 3 is optional. 

E.4.2.8. 2 IM CN subsystem originated RTCP messages 

The MGCF may configure the IM-MGW to detect specific received RTCP packets and forward information derived 
from it by providing a bit pattern(s) for bits 3-15 of incoming RTCP packets as filter criterion in an event descriptor of 
event "RTCP-interworking". Bits 3-7 in the RTCP packet represent the Feedback message type (FMT), and bits 8-15 in 
the RTCP packet represent the Payload type (PT) RTCP header fields, see IETF RFC 4585 [109]. For instance, to 
request that an AVPF Picture Loss Indication (PLI) packet is detected for interworking, the MGCF needs to configure a 
combination of PT=206 (Payload-specific FB message) and FMT=1 (see IETF RFC 4585 [109]). To request that a 
AVPF Temporary Maximum Media Bit-rate Request (TMMBR) packet is detected for interworking, the MGCF needs 
to configure a combination of PT=205 (transport layer feedback message) and FMT=3 (see IETF RFC 5 104 [1 10]). 
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A IM-MGW configured in this way shall check after receiving an incoming RTCP Packet if it is of a desired type, as 
expressed by a bit pattern received from the MGCF. An incoming RTCP message can be of compound format and 
contain several RTCP packets. The IM-MGW shall then perform the check separately for each packet. If the IM-MGW 
determines that the received RTCP packet is of a desired type, the IM-MGW shall send information derived from the 
RTCP message as ObservedEventsDescriptor Parameter(s) of event "RTCP-interworking" in an H.248 "Notify" 
message to the MGCF. 

The information derived from the RTCP message to be sent to the MGCF is listed in table E.4.2.8.2.1. Information 
elements in table E.4.2.8.2.1 shall only be sent if the corresponding RTCP message has been received. 

Table E.4.2.8.2.1 : RTCP information elements to be notified over Mn 



RTCP message 


Information elements transported 
over IVIn interface 


Remarks 


Picture Loss Indication (PLI) {[109]) 


UpdatePicture 




Temporary IVIaximum IVIedia Stream 
Bit Rate Request (TMMBR) ([1 1 0]) 


IVIaxBitRate 


This information indicates the 
maximum media stream bit rate as 
received within the TIVIIVIBR. 



Figure E.4.2.8.2.2.1 shows examples of interactions between RTCP and H.245 for IM CN subsystem originated 
feedback on the quality of the media distribution. 



IMS 


IMMGW 




MGCF 




CSN 


A 


















^ 




/ CALL IN ACTIVE STATE 








N 


1. H.248: MOD.req [C=C1, T=T1... , 
Event=RTCP-lnterworking] 












2. H.248: MOD.resp 




7. send H.245 message 




3. receive RTCP feedback messages 




5. H.248: Notify. req[C=C1,T=T1, 
Event=RTCP-i nterworking] 






4. send RTCP feedback Ack messages 












6. H.248: Notify.resp 




















8. receive H.245 message response 















Figure E.4.2.8.2.2.1 : Interactions between RTCP and H.245 for IIVI CN subsystem originated RTCP 

feedback on the quality of the media distribution 

In signal 1, the MGCF requests the IM-MGW to detect received RTCP feedback message from the IMS side and notify 
the feedback information elements to the MGCF when the interworking is required. To request the IM-MGW to detect 
and notify these feedback information elements, the MGCF shall send the "RTCP-interworking" H.248 event to the IM- 
MGW. The event may be indicated through an H.248 MOD command. 

In signal 3, the IM-MGW receives a RTCP feedback message from the IMS side. 

In signals, the IM-MGW notifies the feedback information elements from RTCP message to the MGCF. 

In signal?, the MGCF send the corresponding H.245 message to the CS side to request for the media adaption. 
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E.4.2.8.3 CS network originated H.245 messages 

Figure E.4.2.8.3.2.1 shows examples of interactions between H.245 and RTCP for CS network originated feedback on 
the quality of the media distribution. 



IMS 



CALL IN ACTIVE STATE 



5. send RTCP feedback message 



6. receive RTCP feedback Ack message 



3. H.248: MOD.req [C=C1 , T=T1.. 
signal=H.245-lnterworking] 



4. H.248: MOD.resp 



CS Network 



1 . receive H.245 message to feedback on the 
quality of the data distribution 



2. send H.245 message response 



Figure E.4.2.8.3.2.1 : Interactions between 1-1.245 and RTCP for CS networit originated 1-1.245 feedbacl< 

on the quality of the media distribution 

In signal 1, the MGCF receives an H.245 feedback message from the CS side. 

In signals, the MGCF requests the IM_MGW to send an RTCP message provisioning the signal "H.245 interworking" 
with parameters identifying information to be transported within this RTCP message. 

In signal5, the IM-MGW send the corresponding RTCP message to the IMS side to request for the media adaption. 

To request the IM-MGW to send an RTCP message, the MGCF shall send the corresponding information elements 
listed in table E.4.2.8.3.2.1 as parameters of the "H.245-interworking signal" over the Mn interface. 

Table E.4.2.8.3.2.1 : Feedback information elements to be indicated 



RTCP message 


Information elements transported 
over Mn Interface 


Remarks 


Picture Loss Indication (PLI) ([109]) 


UpdatePicture 




Temporary Maximum IVIedia Stream 
Bit Rate Request (TMMBR) {[110]) 


IVlaxBitRate 


This information indicates the 
maximum media stream bit rate to be 
sent within the TIVIIVIBR. 



E.4.3 Mn Signalling procedures 
E.4.3.1 Overview 

This subclause describes the logical signalling procedures (i.e. message identifiers are not part of the protocol) between 
the MGCF and IM-MGW. The procedures within this subclause are intended to be implemented using the standard 
H.248 procedure as defined in ITU recommendation H.248. 1 [2] with appropriate parameter combinations. 
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E.4.3.2 Add Multiplex Termination 



This procedure is used to add a termination to multiplex/demultiplex H.223. This procedure containing the 
MuxDescriptor with H.223 value enables the IM-MGW to start the H.324 Multiplexing Level Negotiation. 



Table E.4.3.2. 1: Add Multiplex Termination Procedure 



Procedure 



Initiated 



Information element 
name 



Information 
element 
required 



Information element description 



Add Multiplex 
Termination 



IVIGCF 



Context 



M 



This information element indicates the 
existing context. 



Termination 



IVI 



This information element requests a new 
termination 



IVIuxDescriptor 



IVI 



This information element indicates that data 
multiplexed according to H223 shall be 
received, and from which termination. 



Notify Termination 
Heartbeat 



M 



This information element requests 
termination heartbeat indications 



Notify Released 
Bearer 



O 



This information element requests a 
notification of a released bearer. 



Incoming H.245 

message Notification 

Request 



M 



IVIONA Preferences 



O 



This Event shall indicate that a Notification 
about H.245 messages received by the IM- 
MGW is requested by the IVIGCF 



This information element requests the MGW 
to start a MONA negotiation and provisions 
MONA preferences to be indicated by the 
IIVI-MGW, encoded as described in 
subclause K.6 of ITU-T H.324 [81] 



MONA Preference 
Reception 



O 



This information element requests a 
notification of the reception of the first 
MONA preference message. 



MONA Preference 
Completed 



O 



Legacy Detected 



O 



This information element requests a 
notification of the reception of the first 
MONA preference message with indication 
that the MONA preference negotiation is 
completed. 



MPC Reception 



O 



This information element requests a 
notification of a legacy interworking 
condition. The Event Descriptor also 
embeds a signal descriptor including an 
H.245 message out signal which shall be 
send when legacy interworking is detected 



This information element requests a 
notification of the reception of the first 
MONA preference message with attached 
MPC. 



SPC Reception 



O 



Incoming Multiplex 
Table 



O 



This information element requests a 
notification of the reception of a MONA 
preference message with attached SPC. 



This information element indicates the value 
of the H245 MultiplexEntrySend message 
and allows the MGW to identify incoming 
H.223 MUX PDUs of the channel types 
given in the table. 



MPC Mux Code 



O 



This information element requests the MGW 
to send available media in MPCs and 
indicates the channel type to use for sending 
media. 



Add Multiplex 

Termination 

Ack 



IM-MGW 



Context 



M 



This information element indicates the 
context where the command was executed. 



Termination 



M 



This information element indicates the new 
termination where the command was 
executed. 
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E.4.3.3 Configure Multiplex Termination 

This procedure is used to configure a termination to multiplex/demultiplex H.223. It is also used to exclude some of the 
outgoing MPC channel types due to the MONA Preference received from the peer. 

Table E.4.3.3. 1: Configure Multiplex Termination Procedure 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Configure 

Multiplex 

Termination 


MGCF 


Context 


M 


This information element indicates the 
existing context. 


Termination 


M 


This information element indicates the 
termination 


Remote H223 
Capability 





This information element indicates the 
remote H223 capabilities, as received by the 
MGCF. The element shall not be included if 
the MPC Mux Code IE Is included. 


Incoming Multiplex 
Table 





This information element indicates the value 
of the H245 MultiplexEntrySend message, 
as received by the MGCF from the remote 
H.245 peer. Either this element or the MPC 
Mux Code IE shall be included. 


Outgoing Multiplex 
Table 





This information element indicates the value 
of the H245 MultiplexEntrySend message, 
as sent by the MGCF towards the remote 
H.245 peer. Either this element or the MPC 
Mux Code IE shall be included. 


MPC Mux Code 





This information element requests the MGW 
to continue sending available media in MPC 
and indicates the channel type to use for 
sending media. It is used in this procedure 
only to restrict the list of channel types 
indicated previously in the Add Multiplex 
Termination procedure. Either this element 
or the Incoming and Outgoing Multiplex 
Table elements shall be included. 


Configure 

Multiplex 

Termination 

Ack 


IM-MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Termination 


M 


This information element indicates the 
termination where the command was 
executed. 
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E. 4.3.4 Signal H245 Message 

This procedure is used to send a H245 message to the IM-MGW that the IM-MGW shall forward towards the CS side 
within H.223. 

Table E.4.3.4.1: Signal H245 Message Procedure 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Signal H245 
Message 


MGCF 


Context 


M 


This information element indicates the 
existing context. 


Termination 


M 


This information element indicates the 
termination 


Signal 


M 


This information element indicates the signal 
to request forwarding of a H245 message 
towards the CS side within H.223 


H.245 message 


M 


This information element indicates the H.245 
message to be forwarded 


Signal H245 
Message Ack 


IM-MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Termination 


M 


This information element indicates the 
termination where the command was 
executed. 



E. 4.3.5 Notify H245 Message 

This procedure is used by the IM-MGW to notify the MGCF that the IM-MGW has received a H245 message from the 
CS side within H.223. 

Table E.4.3.5.1: Notify H245 Message Procedure 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Notify H245 
Message 


IM-MGW 


Context 


M 


This information element indicates the 
existing context. 


Termination 


M 


This information element indicates the 
termination 


Event 


M 


This information element indicates the event 
to indicate that a H245 message has been 
received from the CS side within H.223 


H.245 message 


M 


information element indicates the received 
H.245 message 


Notify H245 
Message Ack 


MGCF 


Context 


M 


This information element indicates the 
context where the command was executed. 


Termination 


M 


This information element indicates the 
termination where the command was 
executed. 
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E.4.3.6 Notify MONA Preference Reception 

This procedure is used by the IM-MGW to notify the MGCF that the IM-MGW has received the first MONA 
preference Message from the CS side. 

Table E.4.3.6. 1 : Notify MONA Preference Reception Procedure 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Notify H245 
Message 


IM-MGW 


Context 


M 


This information element indicates the 
existing context. 


Termination 


M 


This information element indicates the 
termination 


Event 


M 


This information element indicates the event 
to indicate that a MONA Preference 
Message has been received 


MONA Preferences 


M 


This information element indicates the 
received MONA preference message 


Notify H245 
Message Ack 


MGCF 


Context 


M 


This information element indicates the 
context where the command was executed. 


Termination 


M 


This information element indicates the 
termination where the command was 
executed. 



E.4.3.7 Notify MONA Preference Completed 

This procedure is used by the IM-MGW to notify the MGCF that the IM-MGW has received the first MONA 
preference Message with indication that the MONA preference negotiation is completed. 

Table E.4.3.7.1: Notify MONA Preference Completed Procedure 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Notify H245 
Message 


IM-MGW 


Context 


M 


This information element indicates the 
existing context. 


Termination 


M 


This information element indicates the 
termination 


Event 


M 


This information element indicates the event 
to indicate that the first MONA preference 
Message with indication that the MONA 
preference negotiation is completed 
received 


Notify H245 
Message Ack 


MGCF 


Context 


M 


This information element indicates the 
context where the command was executed. 


Termination 


M 


This information element indicates the 
termination where the command was 
executed. 
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E.4.3.8 Signal SPC 

This procedure is used to send a H245 message to the IM-MGW that the IM-MGW shall forward towards the CS side 
using the SPC, i.e. as attachment to MONA preference messages. 

Table E.4.3.8.1 : Signal SPC Procedure 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Signal H245 
Message 


MGCF 


Context 


M 


This information element indicates the 
existing context. 


Termination 


M 


This information element indicates the 
termination 


Signal 


M 


This information element indicates the signal 
to request forwarding of a H245 message 
towards the CS side using the SPC, i.e. as 
attachment to MONA preference messages 


H.245 message 


M 


This information element indicates the H.245 
message to be forwarded 


Signal H245 
Message Ack 


IM-MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Termination 


M 


This information element indicates the 
termination where the command was 
executed. 



E.4.3.9 Notify SPC 

This procedure is used by the IM-MGW to notify the MGCF that the IM-MGW has received a H245 message from the 
CS side in SPC PDUs attached to MONA preference messages. 

Table E.4.3.9. 1 : Notify SPC Procedure 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Notify H245 
Message 


IM-MGW 


Context 


M 


This information element indicates the 
existing context. 


Termination 


M 


This information element indicates the 
termination 


Event 


M 


This information element indicates the event 
to indicate that a H245 message has been 
received from the CS side in SPC PDUs 
attached to MONA preference messages 


H.245 message 


M 


information element indicates the received 
H.245 message 


Notify H245 
Message Ack 


MGCF 


Context 


M 


This information element indicates the 
context where the command was executed. 


Termination 


M 


This information element indicates the 
termination where the command was 
executed. 
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E.4.3.10 Notify MPC 

This procedure is used by the IM-MGW to notify the MGCF that the IM-MGW has received the first MONA 
preference message with attached MPC from the CS side. 

Table E.4.3.10.1: Notify MPC Procedure 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Notify H245 
Message 


IM-MGW 


Context 


M 


This information element indicates the 
existing context. 


Termination 


M 


This information element indicates the 
termination 


Event 


M 


This information element indicates the event 
to indicate that the first MONA preference 
message with attached MPC has been 
received. 


MuxCode 


M 


information element that indicates the 
received Channel Type 


Notify H245 
Message Ack 


MGCF 


Context 


M 


This information element indicates the 
context where the command was executed. 


Termination 


M 


This information element indicates the 
termination where the command was 
executed. 



E.4.3.11 Notify Detection of Legacy Interworking 

This procedure is used by the IM-MGW to notify the MGCF that the IM-MGW detects a legacy interworking condition 
that causes it to abort MONA procedures. 

Table E.4.3.11.1 : Notify Detection of Legacy !nterworl<ing Procedure 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Notify H245 
Message 


IM-MGW 


Context 


M 


This information element indicates the 
existing context. 


Termination 


M 


This information element indicates the 
termination 


Event 


M 


This information element indicates the event 
to indicate that a legacy interworking 
condition has been detected. 


Notify H245 
Message Ack 


MGCF 


Context 


M 


This information element indicates the 
context where the command was executed. 


Termination 


M 


This information element indicates the 
termination where the command was 
executed. 
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E. 4.3. 12 Request RTCP-lnterworking 

This procedure is used by the MGCF to request the IM-MGW to detect the RTCP feedback message on the quality of 
the media distribution requiring interworking. 

Table E.4.3.12.1: Request RTCP-lnterworking 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Request RTCP- 
lnterworking 


MGCF 


Context 


M 


This information element indicates the 
existing context. 


Termination 


M 


This information element indicates an 
existing 


RTCPfilter 


M 


This information element provides one or 
several bit pattern{s) for bits 3-15 of an 
RTCP packet. Information from RTCP 
packets that match those patterns shall be 
notified to the MGCF. 


RTCP-lnterworking 


M 


This information element requests a 
notification about information derived from 
the incoming RTCP packet types denoted by 
RTCPfilter. 


Request RTCP- 
lnterworking 
Ack 


IM-MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Termination 


M 


This information element indicates the new 
termination where the command was 
executed. 



E. 4.3.1 3 Notify RTCP-lnterworking 

This procedure is used by the IM-MGW to notify the MGCF the feedback information elements when the IM-MGW 
detects a RTCP feedback message on the quality of the media distribution requiring interworking. 

Table E.4.3.13.1: Notify of RTCP-lnterworking 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Notify RTCP- 
lnterworking 


IM-MGW 


Context 


M 


This information element indicates the 
existing context. 


Termination 


M 


This information element indicates the 
termination 


UpdatePicture 


C 


This information element shall be included 
upon reception of a RTCP PLI message. It 
indicates the request of sending of full intra- 
pictures. 


MaxBitRate 


C 


This information element shall be included 
upon reception of a RTCP TMMBR 
message. It shall contain the bandwidth as 
indicated in the RTCP TMMBR message 
excluding the overhead indicated in the 
RTCP TMMBR message. 


Notify RTCP- 
lnterworking 
Ack 


MGCF 


Context 


M 


This information element indicates the 
context where the command was executed. 


Termination 


M 


This information element indicates the 
termination where the command was 
executed. 
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E.4.3.1 4 Signal-H.245-lnterworking 

This procedure is used by the MGCF to indicate the IM-MGW the feedback information elements when a H.245 
feedback message on the quality of the media distribution requiring interworking is received. 

Table E.4.3.14.1: Signal H.245-lnterworking 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Signal H.245- 
Interworking 


MGCF 


Context 


M 


This information element indicates the 
existing context. 


Termination 


M 


This information element indicates the 
termination 


UpdatePicture 


C 


This information element indicates the 
request to send a RTCP PLI message. 


MaxBitRate 


C 


This information element indicates the 
request to send a RTCP TMBR message. It 
shall contain the bandwidth as indicated in 
the RTCP TMMBR message excluding the 
overhead indicated in the RTCP TMMBR 
message. 


Signal H.245- 

Interworking 

Ack 


IM-MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Termination 


M 


This information element indicates the 
termination where the command was 
executed. 



E.4.3.1 5 Stop MPC 

This procedure is used by the MGC to indicate to the MG that it is no longer allowed to send MPC media encapsulated 
in MONA Preference messages and that it shall stop MPC detection. 

Table E.4.3.15.1 : Stop MPC 



Procedure 


Initiated 


Information 

element 

name 


Information 
element 
required 


Information element description 


Stop MPC 


MGCF 


Context 


M 


This information element indicates the 
existing context. 


Termination 


M 


This information element indicates the 
termination 


Stop MPC Reception 


M 


This information element indicates that the 
reception of MPC encapsulated in MONA 
Preference Messages shall be stopped. 


Stop MPC Sending 


M 


This information element requests that the 
sending of the MPC shall be stopped. 


Stop MPC Ack 


IM-MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Termination 


M 


This information element indicates the 
termination where the command was 
executed. 



E.4.3.1 6 Stop SPC 

This procedure is used by the MGC to indicate to the MG that it is no longer allowed to send MPC media encapsulated 
in MONA Preference messages and that it shall stop SPC detection. 
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Table E.4.3.16.1: Stop MPC 



Procedure 


Initiated 


Information 

element 

name 


Information 
element 
required 


Information element description 


Stop SPC 


MGCF 


Context 


M 


This information element indicates the 
existing context. 


Termination 


M 


This information element indicates the 
termination 


Stop SPC Sending 


IVI 


This information element requests that the 
sending of SPC encapsulated in MONA 
Preference messages shall be stopped. 


Stop SPC Detection 


M 


This information element requests that the 
detection of received SPC encapsulated in 
IVIONA Preference Message shall be 
stopped. 


Stop SPC Ack 


IM-MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Termination 


M 


This information element indicates the 
termination where the command was 
executed. 



E.4.3.17 Stop MONA Negotiation 



This procedme is used by the MGC to request the MG to stop all MONA nogotiation related procedures. 
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Table E.4.3.17.1 : Stop MONA Negotiation 



Procedure 


Initiated 


Information 

element 

name 


Information 
element 
required 


Information element description 


Stop MONA 
Negotiation 


MGCF 


Context 


M 


This information element indicates the 
existing context. 


Termination 


M 


This information element indicates the 
termination 


Stop MONA 

Preference Message 

Sending 


M 


This information element requests that the 
sending of MONA Preference messages be 
stopped. 


Stop MONA 
Detection 


M 


This information element requests that the 
detection of first MONA Preference 
Message and of the MONA negotiation 
completion be stopped. 


Stop SRC Sending 


C 


This information element requests that the 
sending of SPC encapsulated in MONA 
Preference messages be stopped. 
Required only if SPC sending was 
previously configured. 


Stop SPC Detection 


C 


This information element requests that the 
detection of received SPC encapsulated in 
MONA Preference Message be stopped. 
Required only if SPC reception was 
previously configured. 


Stop MPC Reception 


C 


This information element indicates that the 
reception of MPC encapsulated in MONA 
Preference Messages shall be stopped. 
Required only if MPC reception was 
previously configured. 


Stop MPC Sending 


C 


This information element requests that the 
sending of the MPC shall be stopped. 
Required only if MPC sending was 
previously configured. 


Stop MONA 
Negotiation Acl< 


IIVI-MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Termination 


M 


This information element indicates the 
termination where the command was 
executed. 
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Annex F (normative): 
PSTN XML Scheme 

F.1 Scope 

This section defines the PSTN XML Schema to be used for providing the BearerCapabihty, Low Layer Compatibihty, 
High Layer Compatibihty and Progress indicator embedded as body in SIP messages. 

The support of this PSTN XML Schema is a network option. 

F.2 MIME type 

The XML schema defined in the present Annex is registered at lANA as "application/vnd.etsi.pstn+xml" MIME type. 

If the XML scheme is embedded in SIP messages as body, the Content-Type header shall be set to 
"application/vnd.etsi.pstn+xml" and the Content-Disposition shall be set to "signal" with the "handling" parameter set to 
"optional". 



F.3 XML Schema definition 



<?xml version="1.0" encoding="UTF-8"?> 

<xs:schemaxnilns:xs="http://www.w3.org/2001/XMLSchema" xnilns="http://uri.etsi.org/ngn/params/xml/simservs/pstn" 
xmlns:nsl="http://uri.etsi.org/ngn/params/xml/simservs/pstn" targetNamespace="http://uri.etsi.org/ngn/params/xml/simservs/pstn" 
elementFormDefault="qualified"> 
<xs:annotation> 

<xs:documentation>XML Schema definition for mapping of some PSTN into SIP MIME Bodies</xs:documentation> 
</xs : annotation> 
<!— Definition of simple types— > 
<xs:simpleType name="OneBitType"> 
<xs:restriction base="xs:string"> 

<xs:pattern value="[0-l]"/> 
</xs:restriction> 
</xs:simpleType> 

<xs:simpleType name="TwoBitType"> 
<xs:restriction base="xs:string"> 

<xs:pattern value="[0-l][0-l]"/> 
</xs:restriction> 
</xs: simpleType> 

<xs:simpIeType name="ThreeBitType"> 
<xs:restriction base="xs:string"> 

<xs:patternvalue="[0-l][0-l][0-l]7> 
</xs:restriction> 
</xs: simpleType> 

<xs:simpIeType name="FourBitType"> 
<xs:restriction base="xs:string"> 

<xs:pattemvalue="[0-l][0-l][0-l][0-l]7> 
</xs:restriction> 
</xs:simpleType> 

<xs:simpleType name="FiveBitType"> 
<xs:restriction base="xs:string"> 

<xs:patternvalue="[0-l][0-l][0-l][0-l][0-l]7> 
</xs:restriction> 
</xs:simpleType> 

<xs:simpleType name="SixBitType"> 
<xs:restriction base="xs:string"> 

<xs:patternvalue="[0-l][0-l][0-l][0-l][0-l][0-l]7> 
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</xs:restriction> 
</xs: simpleType> 

<xs:simpleType name="SevenBitType"> 
<xs:restriction base="xs:string"> 

<xs:patternvalue="[0-l][0-l][0-l][0-l][0-l][0-l][0-l]7> 
</xs:restriction> 
</xs: simpleType> 
<!— Definition of complex types--> 
<!— Definition of BearerCapability Octets— > 
<xs:complexType name="BCOctet3Type"> 
<xs:sequence> 

<xs:element name="CodingStandard" type="TwoBitT5'pe"/> 
<xs:element name="InformationTransferCapabiIity" type="FiveBitType"/> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="BCOctet4Type"> 
<xs:sequence> 

<xs:element name="TransferMode" type="TwoBitType"/> 
<xs:element name="InformationTransferRate" type="FiveBitType"/> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="BCOctet4-lType"> 
<xs:sequence> 

<xs:element name="RateMultiplier" type="SevenBitType"/> 
</xs:sequence> 
</xs : complexType> 

<xs:complexType name="BCOctet5Type"> 
<xs:sequence> 

<xs:element name="LayerlIdentification" type="TwoBitType"/> 
<xs:element name="UserInfoLayerlProtocol" type="FiveBitType"/> 
</xs:sequence> 
</xs:compIexType> 

<xs:complexType name="BCOctet5aType"> 
<xs:sequence> 

<xs:element name="SynclironousAsynclironous" type="OneBitType"/> 
<xs:element name="Negotiation" type="OneBitType"/> 
<xs:element name="UserRate" type="FiveBitType"/> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="BCOctet5bV110Type"> 
<xs:sequence> 

<xs:element name="IntermediateRate" type="TwoBitType"/> 
<xs:element name="NIConTX" typc="OneBitType"/> 
<xs:element name="NIConRX" typc="OneBitType"/> 
<xs:element name="FIowControlOnTX" typc="OneBitType"/> 
<xs:element name="FIowControlOnRX" typc="OneBitType"/> 
</xs:sequence> 
</xs:compIexType> 

<xs:complexType name="BCOctet5bV120Type"> 
<xs:sequence> 

<xs:element name="RateAdaptionHeader" typc="OneBitType"/> 
<xs:element name="MultipleFrameEstablislimentSupport" typc="OneBitType"/> 
<xs:element name="ModeOfOperation" type="OneBitType"/> 
<xs:element name="LogicalLinkIdentifier" typc="OneBitType"/> 
<xs:element name="Assignor" typc="OneBitType"/> 
<xs:element name="InbandOutbandNegotiation" type="OneBitType"/> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="BCOctet5cType"> 
<xs:sequence> 

<xs:element name="NumberOfStopBits" type="TwoBitType"/> 
<xs:element name="NumberOfDataBits" type="TwoBitType"/> 
<xs:element name="Parity" typc="TlireeBitType"/> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="BCOctet5dType"> 
<xs:sequence> 

<xs:element name="DuplexMode" type="OneBitT)'pe"/> 
<xs:element name="MademType" type="SixBitType"/> 
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</xs:sequence> 
</xs:complexType> 

<xs:complexType name="BCOctet6Type"> 
<xs:sequence> 

<xs:element name="Layer2Identification" type="TwoBitType"/> 
<xs:element name="UserInfoLayer2Protocol" type="FiveBitType"/> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="BCOctet7Type"> 
<xs:sequence> 

<xs:element name="Layer3 Identification" type="TwoBitType"/> 
<xs:element name="UserInfoLayer3Protocol" type="FiveBitType"/> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="BCOctet7aType"> 
<xs:sequence> 

<xs:element name="AdditionaILayer3Info" type="FourBitType"/> 
</xs:sequence> 
</xs : complexType> 

<xs:complexType name="BCOctet7bType"> 
<xs:sequence> 

<xs:element name="AdditionaILayer3Info" type="FourBitType"/> 
</xs:sequence> 
</xs : compIexType> 

<!— Definition of High Layer Compatibility Octets— > 
<xs:complexType name="HLOctet3Type"> 
<xs:sequence> 

<xs:element name="CodingStandard" type="TwoBitType'7> 
<xs:element name="Interpretation" type="TlireeBitType'7> 
<xs:element name="PresentationMethod" type="TwoBitType'7> 
</xs:sequence> 
</xs:compIexType> 

<xs:complexType name="HL0ctet4Type"> 
<xs:sequence> 

<xs:element name="HighLayerCharacteristics" type="SevenBitType'7> 
</xs:sequence> 
</xs : complexType> 

<xs:complexType name="HLOctet4aMaintenanceT)'pe"> 
<xs:sequence> 

<xs:element name="HighLayerCharacteristics" type="SevenBitType'V> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="F[LOctet4aAudioType"> 
<xs:sequence> 

<xs:element name="VideoTelepiionyCliaracteristics" type="SevenBitType'7> 
</xs:sequence> 
</xs:complexType> 

<!— Definition of Low Layer Compatibility Octets— > 
<xs:complexType name="LLOctet3Type"> 
<xs:sequence> 

<xs:element name="CodingStandard" type="TwoBitType'7> 
<xs:element name="InformationTransferCapability" type="FiveBitType'7> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="LLOctet3aType"> 
<xs:sequence> 

<xs:element name="NegotiationIndicator" type="OneBitType'7> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="LL0ctet4Type"> 
<xs:sequence> 

<xs:element name="TransferMode" typc="TwoBitType'7> 
<xs:element name="InformationTransferRate" type="FiveBitType'7> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="LLOctet4-lType"> 
<xs:sequence> 

<xs:element name="RateMultipIier" type="SevenBitType'7> 
</xs:sequence> 
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</xs:complexType> 

<xs:complexType name="LLOctet5Type"> 
<xs:sequence> 

<xs:element name="Layerl Identification" type="TwoBitType"/> 
<xs:element name="UserInfoLayerlProtocol" type="FiveBitType"/> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="LLOctet5aType"> 
<xs:sequence> 

<xs:element name="SynclironousAsynciironous" type="OneBitType"/> 
<xs:element name="Negotiation" type="OneBitType"/> 
<xs:element name="UserRate" type="FiveBitType"/> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="LL0ctet5bVl 10Type"> 
<xs:sequence> 

<xs:element name="IntermediateRate" type="TwoBitType"/> 
<xs:element name="NIConTX" typc="OneBitType"/> 
<xs:element name="NIConRX" typc="OneBitType"/> 
<xs:element name="FlowControlOnTX" typc="OneBitType"/> 
<xs:element name="FlowControlOnRX" typc="OneBitType"/> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="LLOctet5bV120Type"> 
<xs:sequence> 

<xs:element name="RateAdaptionHeader" type="OneBitType"/> 
<xs:element name="MuItipleFrameEstabIislimentSupport" typc="OneBitType"/> 
<xs:element name="ModeOfOperation" type="OneBitType"/> 
<xs:element name="LogicalLinkIdentifier" typc="OneBitType"/> 
<xs:element name="Assignor" typc="OneBitType"/> 
<xs:element name="InbandOutbandNegotiation" type="OneBitType"/> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="LLOctet5cType"> 
<xs:sequence> 

<xs:element name="NumberOfStopBits" typc="TwoBitType"/> 
<xs:element name="NumberOfDataBits" typc="TwoBitType"/> 
<xs:element name="Parity" type="ThreeBitType"/> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="LLOctet5dType"> 
<xs:sequence> 

<xs:element name="DupIexMode" type="OneBitType"/> 
<xs:element name="ModemType" type="SixBitType"/> 
</xs:sequence> 
</xs:compIexType> 

<xs:complexType name="LLOctet6Type"> 
<xs:sequence> 

<xs:element name="Layer2Identification" type="TwoBitType"/> 
<xs:element name="UserInfoLayer2Protocol" type="FiveBitType"/> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="LLOctet6aHDLCType"> 
<xs:sequence> 

<xs:element name="Mode" type="TwoBitT)'pe"/> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="LL0ctet6aUserSpecificType"> 
<xs:sequence> 

<xs:element name="UserSpecificLayer2Information" type="SevenBitType"/> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="LLOctet6bType"> 
<xs:sequence> 

<xs:element name="WindowSize" type="SevenBitType"/> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="LLOctet7Type"> 
<xs:sequence> 
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<xs:element name="Layer3Identification" type="TwoBitType"/> 
<xs:element name="UserInfoLayer3Protocol" type="FiveBitType"/> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="LL0ctet7aUserSpecificType"> 
<xs:sequence> 

<xs:element name="OptionalLayer3Information" type="SevenBitType"/> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="LLOctet7aX25Type"> 
<xs:sequence> 

<xs:element name="Mode" type="TwoBitType"/> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="LLOctet7bX25Type"> 
<xs:sequence> 

<xs:element name="DefaultPacketSize" type="FourBitType'7> 
</xs:sequence> 
</xs : complexType> 

<xs:complexType name="LL0ctet7cType"> 
<xs:sequence> 

<xs:element name="PacketWindowSize" typc="SevenBitType"/> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="LLOctet7aTR9577Type"> 
<xs:sequence> 

<xs:element name="AdditionalLayer3Info" type="FourBitType'7> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="LLOctet7bTR9577Type"> 
<xs:sequence> 

<xs:element name="AdditionalLayer3Info" type="FourBitType'7> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="DispOctet3Type"> 
<xs:sequence> 

<xs:element name="DisplayInformation" typc="SevenBitType'7> 
</xs:sequence> 
</xs : complexType> 

<!— Definition of tlie information elements— > 
<xs:complexType name="BearerCapabilityType"> 
<xs:sequence> 

<xs:element name="BCoctet3" typc="BCOctet3Type'7> 
<xs:element name="BCoctet4" type="BCOctet4Type'7> 
<xs:element name="BCoctet4-l" type="BC0ctet4-lType" minOccurs="0'7> 
<xs:element name="BCoctet5" type="BC0ctet5Type" minOccurs="0'7> 
<xs:element name="BCoctet5a" typc="BCOctet5aType" minOccurs="0'7> 
<xs:element name="BCoctet5bV110" type="BCOctet5bV110Type" minOccurs="0'7> 
<xs:element name="BCoctet5bV120" type="BCOctet5bV120Type" minOccurs="0'7> 
<xs:element name="BCoctet5c" type="BCOctet5cType" minOccurs="0'7> 
<xs:element name="BCoctet5d" type="BCOctet5dType" minOccurs="0'7> 
<xs:element name="BCoctet6" typc="BC0ctet6Type" minOccurs="0'7> 
<xs:element name="BCoctet7" type="BC0ctet7Type" minOccurs="0'7> 
<xs:element name="BCoctet7a" typc="BCOctet7aType" minOccurs="0'7> 
<xs:element name="BCoctet7b" type="BCOctet7bType" minOccurs="0'7> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="HighLayerCompatibilityType"> 
<xs:sequence> 

<xs:element name="HL0ctet3" typc="HLOctet3Type'7> 
<xs:element name="HL0ctet4" typc="HLOctet4Type'7> 

<xs:element name="HL0ctet4aMaintenance" type="HL0ctet4aMaintenanceType" minOccurs="0'7> 
<xs:element name="HLOctet4Audio" type="HLOctet4aAudioType" iTiinOccurs="0'7> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="LowLayerCompatibilityType"> 
<xs:sequence> 

<xs:element name="LL0ctet3" type="LLOctet3Type'7> 

<xs:element name="LL0ctet3a" type="LL0ctet3aType" minOccurs="0'7> 
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<xs:element name="LLOctet4" type="LLOctet4Type"/> 
<xs:element name="LL0ctet4-l" type="LL0ctet4-lType" minOccurs="0"/> 
<xs:element name="LL0ctet5" type="LL0ctet5Type" minOccurs="0"/> 
<xs:element name="LL0ctet5a" type="LL0ctet5aType" minOccurs="0"/> 
<xs:element name="LLOctet5bV110" type="LLOctet5bV110Type" minOccurs="0"/> 
<xs:element name="LLOctet5bV120" type="LLOctet5bV120Type" minOccurs="0"/> 
<xs:element name="LL0ctet5c" type="LLOctet5cType" minOccurs="0"/> 
<xs:element name="LL0ctet5d" type="LLOctet5dType" minOccurs="0"/> 
<xs:element name="LL0ctet6" type="LLOctet6Type" minOccurs="0"/> 
<xs:element name="LLOctet6aHDLC" type="LLOctet6aHDLCType" minOccurs="0"/> 
<xs:element name="LL0ctet6aUserSpecific" type="LLOctet6aUserSpecificType" minOccurs="0"/> 
<xs:element name="LL0ctet6b" type="LLOctet6bType" minOccurs="0"/> 
<xs:element name="LL0ctet7" type="LL0ctet7Type" minOccurs="0"/> 

<xs:element name="LL0ctet7aUserSpecific" type="LLOctet7aUserSpecificType" iTiinOccurs="0"/> 
<xs:element name="LLOctet7aX25" type="LLOctet7aX25Type" minOccurs="0"/> 
<xs:element name="LLOctet7bX25" typc="LLOctet7bX25Type" iTiinOccurs="0"/> 
<xs:element name="LL0ctet7c" type="LLOctet7cType" minOccurs="0"/> 
<xs:element name="LLOctet7aTR9577" typc="LLOctet7aTR9577Type" minOccurs="0"/> 
<xs:element name="LLOctet7bTR9577" type="LLOctet7bTR9577Type" minOccurs="0"/> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="DisplayType"> 
<xs:sequence> 

<xs:element name="DispOctet3" type="DispOctet3Type"/> 
</xs:sequence> 
</xs : complexType> 
<!— Definition of progress indicator— > 
<xs:complexType name="ProgressOctet3Type"> 
<xs:sequence> 

<xs:element name="CodingStandard" typc="TwoBitType"/> 
<xs:element name="Location" type="FourBitType "/> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="ProgressOctet4Type"> 
<xs:sequence> 

<xs:element name="ProgressDescription" type="SevenBitType"/> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="ProgressIndicatorType"> 
<xs:sequence> 

<xs:element name="ProgressOctet3" type="ProgressOctet3Type"/> 
<xs:element name="ProgressOctet4" type="ProgressOctet4Type"/> 
</xs:sequence> 
</xs : complexType> 
<!— Definition of document structure— > 
<xs:element name="PSTN"> 
<xs:complexType> 
<xs:sequence> 

<xs:element name="BearerCapability" type="BearerCapabilityType" minOccurs="0" maxOccurs="2"/> 
<xs:element name="HighLayerCompatibility" type="HighLayerCompatibilityType" niinOccurs="0" 
maxOccurs="2"/> 

<xs:element name="LowLayerCompatibility" type="LowLayerCompatibilityType" minOccurs="0"/> 
<xs:element name="ProgressIndicator" type="ProgressIndicatorType" minOccurs="0" maxOccurs="unbounded'7> 
<xs:element name="Display" type="DisplayType" minOccurs="0" maxOccurs="unbounded"/> 
<xs:element name="sendingCompleteIndication" minOccurs="0"/> 
</xs:sequence> 
</xs:complexType> 
</xs:element> 
</xs:schema> 



F.4 lANA registration template 



Within the present subclause, information required for an lANA registration at http://www.iana.org/cgi- 
bin/mediatypes.pl is provided. 



ETSI 



3GPP TS 29.1 63 version 9.1 3.0 Release 9 292 ETSI TS 1 29 1 63 V9.1 3.0 (201 3-04) 

1 . Media Type Name 
Application 

2. Subtype name 
"vnd.etsi.pstn+xml" (Vendor Tree) 

3. Required parameters 
none 

4. Optional parameters 
none 

5. Encoding considerations 
binary 

6. Security considerations 

The security considerations for XML in RFC 3023 apply. 

Modifications of the MIME body by a man-in-the-middle can have severe consequences: 

The information derived from ISUP that can be transported with this MIME body influence the call handling of the SIP 
session that is being setup. 

However, this MIME body is used only attached to SIP messages, and modifications of other parts of the SIP signalling 
will lead to comparable consequences. Protection of the SIP signalling will also protect the present MIME body. The 
SIP signalling should be protected as described in RFC 3261. 

7. Interoperability considerations 
None 

8. Published specification 
3GPPTS 29.163 

9. Applications which use this media type 

This MIME type is used as a message body within SIP messages. 

It is used for sending information derived from ISUP or DSSl signalling with no SIP equivalent. 

10. Additional information 
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Magic number(s): none (see RFC 3023) 
File extension(s): ".xml" (see RFC 3023) 
Macintosh File Type Code(s): "Text" (see RFC 3023) 
Object Identifier(s) or OID(s): none 

1 1 . Intended usage 
Limited Use 

12. Other Information/General Comment 

The content of this MIME type is UTF-8 encoded. The charset parameter is not used. 
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Annex G (normative): 
Overlap digit message body 

G.1 Scope 

This section defines a message body that shall be used for sending additional digits, which have not previously been 
sent, in SIP INFO messages ("legacy" mode of usage of the INFO method as defined in IETF RFC 6086 [133]) when 
the in-dialog method is used for overlap dialling. 

The same message body can also be used for transporting Dual Tone Multi Frequency (DTMF) tones using SIP INFO 
requests, using the DTMF info package (see IETF RFC 6086 [133]) defined in Annex P of 3GPP TS 24.229 [9]. 

The support of this message body is a network option. 



G.2 IVIIIVIEtype 

The message body defined in the present Annex is registered at lANA as "application/session-info" MIME type. 

If the message body is embedded in SIP INFO messages, the Content-Type header shall be set to "application/session- 
info" and the Content-Disposition header shall be set to "signal" with the handling parameter set to "optional". 



G.3 ABNF 



session-info = SubsequentDigit 

SubsequentDigit = "SubsequentDigit" HCOLON phonedigits 

phonedigits = 1*(HEXDIG / "*" / "#") 

HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 



G.4 lANA registration template 



Within the present subclause, information required for an lANA registration at http://www.iana.org/cgi- 
bin/mediatypes.pl is provided. 



1 . Media Type Name 
Application 

2. Subtype name 
"session-info" (Standards Tree) 

3. Required parameters 
none 
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4. Optional parameters 
none 



5. Encoding considerations 
binary 

6. Security considerations 

Modifications of the MIME body by a man-in-the-middle can have severe consequences: 

The overlap digits that can be transported with this MIME body influence the routeing of the SIP session that is being 
setup. 

Dual Tone Multi Frequency (DTMF) tones that can also be transported with this MIME body will be interpreted by the 
application of the end points of the communication for various purposes. 

However, this MIME body is used only attached to SIP INFO messages, and modifications of other parts of the SIP 
signalling will lead to comparable consequences. Protection of the SIP signalling will also protect the present MIME 
body. The SIP signalling should be protected as described in RFC 3261. 

7. Interoperability considerations 
none 



8. Published specification 
3GPPTS 29.163 

9. Applications which use this media type 

This MIME type is used as a message body within SIP INFO messages. 

It is either used for sending additional digits of the callee's number, which have not previously been sent, in SIP INFO 
messages ("legacy" mode of usage of the INFO method as defined in IETF RFC 6086) when the in-dialog method is 
used for overlap dialling. 

The same message body can also be used for transporting Dual Tone Multi Frequency (DTMF) tones using SIP INFO 
requests, using the DTMF info package (see RFC 6086) defined in Annex P of 3GPP TS 24.229. 

10. Additional information 
Magic number(s): none 
File extension(s): none 
Macintosh File Type Code(s): none 
Object Identifier(s) or OID(s): none 

1 1 . Intended usage 
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Limited Use 



12. Other Information/General Comment 



none. 
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Annex H (normative): 

Interworking of Originating Line Information (OLI) parameter 

(network option) 

H.1 Interworking SIP to ISUP 

The "oli" URI parameter received within tel URI or the userinfo part of SIP URI with user="phone" (as defined in 
subclause 7.2A.12 of 3GPP TS 24.229 [9]) received in a P-Asserted-Identity header in the initial INVITE request shall 
be used to set the ISUP lAM OLI parameter. In case the P-Asserted-Identity URI "oli" parameter is absent then the 
ISUP lAM OLI parameter shall be omitted. 

H.2 Interworking ISUP to SIP 

The ISUP lAM OLI parameter shall be used to set the "oli" URI parameter within tel URI or the userinfo part of SIP 
URI with user="phone" parameter (as defined in subclause 7.2A.12 of 3GPP TS 24.229 [9]) of a P-Asserted-Identity 
header in the initial INVITE request. In case the ISUP lAM OLI parameter is absent then the P-Asserted-Identity URI 
"oli" parameter shall be omitted from the initial INVITE request. 
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Annex I (normative): 

GTT interworking between the IP Multimedia Core Network 

(CN) Subsystem (IMS) and Circuit Switched (CS) networks 



1.1 Overview of GTT interworking between the IMS and 
Circuit Switched (CS) networks 

The support of Global Text Telephony (GTT) is optional, but may be required by national regulatory requirements. If 
GTT is supported, the procedures described within this Annex shall be applied. 

Global Text Telephony (GTT) offers real time conversation in text, optionally combined with voice. GTT is mainly 
used for distant conversation with hearing or speech impaired users. 

GTT is supported in IMS via the Real-Time Text protocol over RTP, using IETF SIP/SDP for the negotiation of the text 
media and IETF RFC 4103 [124] RTP -text for transport, with text coded according to ITU-T Recommendation 
T.140 [123]. See 3GPP TS 23.226 [122], 3GPP TS 26.114 [104], 3GPP TS 26.235 [127] and 3GPP TS 26.236 [128]. 

In PSTN, different specified systems for text telephony exist and are used in different regions, e.g. Baudot (in US), 
EDT, V.21, Belll03, Minitel and V.18. They all use different modem technologies within PCM and different character 
coding for the transmission of text. They are described in the annexes of ITU-T Recommendation V.18 [125]. ITU-T 
Recommendation V.18 [125] is an international text telephone modem standard with an automoding mechanism that 
enables communication with all the different kinds of PSTN text telephone systems. Any party of a GTT call may at 
any time initiate text or send voice. Speech and text may be used in an alternating manner during a conversation on the 
PSTN. It is also possible that speech is transferred in one direction and text in the opposite direction. However, speech 
and text can not be used in the same direction at the same time in most sub-modes of V.18. 

In the 3GPP CS radio interface, a dedicated CTM modem is used (see 3GPP TS 26.226 [126]), which is terminated 
within the CS domain and interworked to PTSN inband text telephony format. 

Interworking between Real-Time Text over RTP within IMS and PSTN text telephony is provided at the MGCF / IM- 
MGW by the MGCF triggering the insertion of an Interworking (conversion) function within the IM-MGW which then 
behaves in accordance with ITU-T Recommendation V.18 [125] or any of its specific sub-modes. 

The support of this Interworking function between IP-based Real-Time Text over RTP and modem based transmission 
of real-time text is optional both at the MGCF and IM-MGW, but can be required by national regulatory bodies. If this 
Interworking function is supported, the procedures described within this Annex shall be applied. 

The Interworking function in the IM-MGW shall support the detection of text modem signals on the CS side and the 
conversion between text/modem signals and Real-Time Text over RTP. 

The IM_MGW shall support at least one of the sub-modes listed in ITU-T Recommendation V.18 [125] (e.g. Baudot). 
The support of any of the sub-modes is optional. 

The procedures to detect and convert text/modem involve expensive MGW resources. The present GTT interworking 
procedures intend to allow cost effective implementations by avoiding additional load or resources in MGW for calls 
not using text telephony (which represent most of the calls). 

It is assumed that IMS terminals supporting text media will not automatically offer text media, but that this will be 
instead governed by terminal configuration options and user interactions to suit the communication preferences and 
abilities of the user. However, an IMS terminal desiring to set up a GTT call will offer Real-Time Text media, possibly 
in parallel to voice media. The IMS-MGW shall then provide the conversion between Real-Time Text over RTP and 
text/modem signals. On the contrary, if the mobile does not request Real-Time Text support, no Interworking function 
is necessary. An IMS Multimedia terminal configured to use Real-Time Text Telephony but receiving an SDP offer for 
voice-only media will accept this offer and then send an own subsequent SDP offer adding text media. When receiving 
such a subsequent offer for text media, the IMS-MGW shall provide the conversion between Real-Time Text over RTP 
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and text/modem signals at the CS interface. On the contrary, if the mobile does not offer Real-Time Text, no 
Interworking function is necessary. 



1.2 Control plane interworking 

1.2.1 General 

Before text conversation can begin, a call shall first be established, from PSTN to IMS or vice-versa. The ISUP or 
BICC signalling to/from the PSTN indicates a "speech" call, without any GTT indication. 

The IMS user may request a text connection from the beginning of a call, or add request for Real-Time Text media at a 
later stage in a call that was originally established with audio only. 

1.2.2 Functionalities required in the MGCF for GTT calls support 

In addition to the control plane interworking between SIP and ISUP or BICC (see clause 7), the MGCF shall support the 
negotiation of the Real-Time Text payload type (T. 140 Text Conversation MIME media type as specified by IETF RFC 
4103 [124]) in a distinct SDP m-line. 

1.2.3 IM CN subsystem originated session 

1.2.3.1 Initial INVITE with an SDP offer including a text media line 

Figure 1.2.3.1.1 shows an example call flow where the IMS terminal requests Real-Time Text telephony by sending an 
SDP offer including one audio line and one text media line within an initial INVITE message. 
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Interworking Node 
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CS Network 

2. lAM (speech) 














3. SIP: 18xor200OK 
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Figure 1.2.3.1.1 : IM CN subsystem originated session - Initial INVITE offering audio and text 

Upon receipt of a SIP INVITE request offering text media (possibly combined with audio media) (signal 1 in figure 
1.2.3.1.1) the Interworking Node (MGCF) starts the call set-up at the CS side by sending an lAM requesting a speech 
with G.7I I codec only or 3.1 Khz bearer (signal 2 in figure 1.2.3.1.1), and completes the call setup on IMS and CS side 
using the procedures specified in clause 7, but returning an SDP answer including Real-Time Text media (possibly 
combined with audio media if audio media has been offered) (signal 3 in figure 1.2.3.1.1). 

The MGCF triggers the insertion an Interworking function in the IM-MGW for the duration of the call if a Real-Time 
Text media stream is established. 
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The MGCF reserves corresponding Real-Time Text media resources in the IM-MGW and activate the Interworking 
function, and if resources were available, return an SDP answer with audio and Real-Time Text. 

1.2.4 CS network originated session 

1.2.4.1 General 

When starting the session setup signalling from a CS based network towards the IMS, the MGCF has no knowledge 
whether the CS side terminal supports and will accept to use text telephony. 

1.2.4.2 Initial INVITE with an SDP offer including audio only 

The MGCF offers only audio media when setting up a call towards the IMS and waits for IMS terminals desiring Real- 
Time Text media to send a new offer adding Real-Time Text media attribute prior to inserting an Interworking function 
in the IM-MGW. If the MGCF receives a new offer adding Real-Time Text media and applies signalling with OoBTC 
on the CS CN, the MGCF shall apply appropriate OoBTC procedures to only select G.711 audio codec on the CS call 
leg. 

Figure 1.2.4.2.1 shows an example call flow. 



CS Network 



Interworking Node 
(MGCF) 



1. lAM (speech) 



Bearer Establishment 



.ACM 



13.ANM 



IMS 



2. SIP: INVITE 
[SDP offer: Audio] 



3. SIP: 1 83 Session Progress 
[SDP answer: Audio] 



4. SIP: PRACK 



5. SIP: 200 OK (PRACK) 



6. SIP: UPDATE [SDP offer: Audio + Text] 



7. SIP: 200 UPDATE 
[SDP answer: Audio + Text] 



8. SIP: 180 Ringing 



10. SIP: PRACK 



1 1 . SIP: 200 OK (PRACK) 



12. SIP: 200 OK (INVITE) 



Audio / Text 



Figure 1.2.4.2.1 : CS originated session - Initial INVITE offering audio only 

Upon receipt of an lAM request for a speech or 3. 1 Khz audio call (signal 1 in figure 1.2.4.2. 1) the Interworking Node 
(MGCF) starts the call set-up at the IM CN subsystem side by sending an INVITE request (signal 2 in figure 1.2.4.2.1) 
offering audio media applying the interworking procedures in clause 7. 
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IMS terminals supporting GTT and configured to use it will send a new SDP offer including an audio and a Real-Time 
Text media line within a subsequent UPDATE or re-INVITE request. 

When GTT interworking between IMS and CS networks is required, the MGCF shall reserve corresponding Real-Time 
Text media resources in the IM-MGW and thereby request the insertion of the Interworking function, and if resources 
were available, return an SDP answer with audio and Real-Time Text media attributes. 



1.2.5 Subsequent SDP offer/answer exchange adding text to an 
audio session 

If only audio media has been offered in the initial SDP offer, the IMS terminal can also request GTT support by sending 
a new SDP offer including audio and Real-Time Text when a SIP dialogue (early or confirmed) has already been 
established. 

The MGCF shall then trigger the insertion of an Interworking function in the IM-MGW following the same principles 
as those specified in subclause 1.2.3.14. However, if OoBTC signalling is supported and a codec other than PCM 
(default G.71 1) has been selected at the CS network, then a codec modification is required to G.71 1. Otherwise No 
additional ISUP or BICC signalling towards the CS network is required. 



1.3 User plane interworking 

1.3.1 Functionalities required in the IM-MGW for GTT support 

An IM-MGW supporting GTT interworking between IMS and CS network shall support: 

- Real-Time Text as specified in 3GPP TS 26.235 [127], 3GPP TS 26.236 [128] and 3GPP TS 26.114 [104] for a 
Multimedia Telephony Service Indicator (MTSI) compliant IM-MGW; this includes: 

requirement to support ITU-T Recommendation T. 140 [123] Text Conversation MIME media type and RTP- 
text transport as specified by IETF RFC 4103 [124] and ITU-T Recommendation T.140 [123] Text 
Conversation presentation coding; 

recommended support of redundancy coding variant specified in IETF RFC 4103 [124] for error resilience; 

PSTN based text telephony using ITU-T Recommendation V. 18 [4] or any of its specific sub-modes. 

NOTE: One specific text telephone protocol of the ITU-T Recommendation V.18 standard, called "Baudot Code" 
(Baudot modulation at 45.45 baud), is particularly important for support of emergency calls in US. 

1.3.2 Monitoring of text/modem signals on the CS side 

When the IMS session is setup with text media (possibly combined with audio media), the MGCF thereby requests the 
IM-MGW to monitor the CS termination for possible receipt of text telephone signals, in order to detect whether the CS 
user wishes to transit from voice to text during a voice call. The IM-MGW shall be provisioned with the text telephone 
mode(s) for which the termination should be monitored. The presence of the text media in the IMS session is an explicit 
indication that monitoring of text telephone signals is required. 

When monitoring for text telephony signals the IM-MGW should listen on the CS side voice line for text telephone 
signals, and shall not transmit modem tones from the CS side termination to IMS side termination until one of the 
following occurs: 

1) If the PSTN terminal is a carrier-based device and transmits answer tone. The IM-MGW shall then resolve the 
text telephone mode according to V.18 procedures and then operate in that mode; 

2) If the PSTN terminal is a carrier-less device, the end user starts sending characters such that these may be 
detected by the IM-MGW. The IM-MGW shall then detect the text telephone mode and then operate in that 
mode. 
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If the IMS terminal transmits text characters first the IM-MGW shall initiate a text connection toward the CS network 
and resolve the textphone type, so that communication can continue in text mode. 

See ITU-T Recommendation V.18 [125] for a detailed description of those procedures. 

1.3.3 Multiplexing between the CS and IIVIS streams 

The IM-MGW should remain in speech mode until such time that text is detected from either user. The IM-MGW shall 
detect modem signals on the CS termination and decide based on this detection if the media received from the CS side 
is interworked to the speech or the text media stream on the IMS side. In the media direction towards the CS network, 
the IM-MGW needs to multiplex both media streams into the PCM signal. 

The following procedures provide further information on the procedures to be followed by the IM-MGW, for normative 
behaviour the ITU-T Recommendation V.18 [125] shall be followed. 

Carrier text phone: 

After a carrier mode text connection is established, loss of carrier can be taken as the indication that the audio 
stream on the IMS termination shall be connected with the (PCM) interface of the line on the CS termination. 

When the text carrier reappears on the CS termination, or text is received from the text media stream on the 
IMS termination, the IM-MGW connects the text stream on the IMS termination with the (PCM) interface of 
the line on the CS termination. 

Carrierless text phone: 

When the V.18 modem detects text, the textphone CS termination stops feeding the audio stream of the IMS 
termination, and instead inserts the detected and T.140 converted characters into the text stream of the IMS 
termination. This mode is continued as long as characters keep coming from the PSTN textphone. When no 
more characters arrive, and no textphone signal is received within 1 second, the audio channel is again fed to 
the audio stream of the IMS termination. If new text comes from the V.18 side, the process is repeated. 

If text is received from the text stream of the IMS termination when V . 1 8 is not actively receiving text, no 
media shall be applied to the IMS audio stream, and the characters are sent to the V.18 modem for 
transmission. When all text is transmitted and no more is received for two seconds, the audio channels are 
enabled again. Since the carrierless systems are one-way alternate transmission systems, transmission of 
characters is possible only in one direction at a time. Once started, reception is given priority. Characters 
received from text stream of the IMS termination while V. 18 is busy receiving should be buffered (up to a 
reasonable limit). 

1.3.4 Conversion between text/modem and Real-Time Text over 
RTP 

The legacy PSTN textphone modes have limited character sets. For all legacy modes, the text received through the V.18 
modem shall be converted if necessary in the RTP/T.140 format for the text stream on the IMS termination, according 
to the rules in ITU-T Recommendation. T.140 [123] and IETF RFC 4103 [124], and vice-versa. 

Redundancy may be used as specified in IETF RFC 4103 [124]. Use or not of redundancy is derived from the text 
media description configured on the IMS termination (RTP/RED/T.140). 



1.4 MGCF and IIVI-IVIGW interactions 
1.4.1 Introduction 

This subclause describes requirements for extensions to the Mn interface protocol in 3GPP TS 29.332 [15] needed to 
support the Interworking of Real-Time Text Telephony media in IMS with text/modem calls in CS domain. 
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1.4.2 Mn signalling interactions 

1.4.2.1 Introduction 

The following subclauses describe the Mn interface procedures. 
All message sequence charts in these subclauses are examples. 

1.4.2.2 H.248 Context IVIodel 

The H.248 context model depicted in figure 1.4.2.2.1 shall be applied for interworking Real-Time Text media in IMS to 
text/modem in CS. 



>l 



t fgudio +\V.18) strqa m 



Real-Time \ 

Text/RTP stre&m Termination Tl Termination T2 



CS network 



Figure 1.4.2.2.1 : H.248 Context Model for GTT support 

The H.248 context contains one IP termination (IMS side) with two streams (one stream for Real-Time Text/RTP, 
another stream for audio/RTP), plus a TDM, AAL2 or IP termination (CS side) with one single stream carrying both 
voice via PCM and V.18 text telephony. 

1.4.2.3 Specific IVIn signalling for GTT 

The following information shall be provided from the MGCF towards the IM-MGW: 

SDP with audio and Real-Time Text m-lines for the IMS termination; 

- PCM (G.711) codec for the CS side termination. 

This shall trigger the IM-MGW to insert an IWF to support RTT to PSTN text telephony conversion. If the topology is 
incoming (or bothway) from the CS network the IM-MGW shall monitor for text telephony and convert to RTT towards 
the IMS network. If the topology is outgoing (or bothway) to the CS network the IM-MGW shall multiplex RTT 
payload into the PCM stream. 
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1.4.2.4 IM CN subsystem originated session between tine MGCF and IM- 
MGW 

1.4.2.4.1 Initial INVITE with an SDP offer including Real-Time Text 
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Next steps of t>asic call establishment (as specified in subclause 9.2.2.3), returning an SDP Answer with audio + text 
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Figure 1.4.2.4.1.1 : Example Mn signalling interactions for IMS originated session with audio and text 

The Mn signalling interactions specified in subclause 9.2.2.3 shall apply, with the following differences. 

When reserving the IMS termination, the MGCF shall configure two streams; one for the audio and one for the Real- 
Time Text media line, with their respective media description (signal 3 in figure 1.4.2.4.1.1). Monitoring of text 
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telephony at the CS side termination is indicated by the inclusion of Real-Time Text media at the IMS side termination 
and by the topology being bothway or incoming from the CS side. 

The text telephone mode(s) for which the CS side termination is monitored shall be provisioned in the IM-MGW. 
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1.4.2.5 CS network originated session 

1.4.2.5.1 Initial INVITE with an SDP offer only including audio 
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Figure 1.4.2.5.1 .1 : Mn signalling interactions for CS originated session - Initial INVITE with audio only 

The Mn signalling interactions specified in subclause 9.2.3.3 shall apply, with the following differences. 
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Upon receipt of a subsequent SDP offer from the IMS terminal including the audio and Real-Time Text media lines, the 
MGCF shall add an additional text stream to the IMS termination and configure it with the remote media description 
(signal 13 in figure 1.4.2.5.1.1). 



1.4.3 Mn Signalling procedures 
1.4.3.1 Overview 

This subclause describes the logical signalling procedures (i.e. message identifiers are not part of the protocol) between 
the MGCF and IM-MGW. The procedures within this subclause are intended to be implemented using the standard 
H.248 procedure as defined in ITU recommendation H. 248.1 [2] with appropriate parameter combinations. 

The procedures "Reserve IMS connection point" and "Configure IMS resources" and "Reserve IMS Connection point 
and configure remote resources" shall allow the configuration of two media streams; one for audio and one for Real- 
Time Text on the IMS termination. See subclause 9.3.1. 
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NP#24 


NP-040242 


042 


2 


Codec negotiation - Mid call interworking 


6.2.0 


6.3.0 


2004-06 


NP#24 


NP-040242 


043 




Codec parameter translation - IM CN subsystem to BICN 


6.2.0 


6.3.0 


2004-06 


NP#24 


NP-040242 


044 


2 


MGCF IM-MGW interactions 


6.2.0 


6.3.0 


2004-06 


NP#24 


NP-040241 


045 




Notify IMS RTP Tel Event (same as "Report DTMF") message 
sequence shows lEs that are not used with this procedure 


6.2.0 


6.3.0 


2004-06 


NP#24 


NP-040241 


046 




Correction of sub-clause 7.2.3.2.5.1 Backward call indicators 


6.2.0 


6.3.0 


2004-09 


NP#25 


NP-040334 


050 


3 


Corrections to AMR codec parameter translations 


6.3.0 


6.4.0 


2004-09 


NP#25 


NP-040346 


048 


2 


Non call-related Mc procedures 


6.3.0 


6.4.0 


2004-12 


NP#26 


NP-040582 


059 




Editorial mistake in Table 12 


6.4.0 


6.5.0 


2004-12 


NP#26 


NP-040582 


056 


1 


Corrections to EFR codec parameters 


6.4.0 


6.5.0 


2004-12 


NP#26 


NP-040582 


057 


2 


DTMF towards IM CN subsystem 


6.4.0 


6.5.0 


2004-12 


NP#26 


NP-040582 


054 


3 


Mapping of continuity signal 


6.4.0 


6.5.0 


2004-12 


NP#26 


NP-040583 


058 


2 


Clarifications for Mn procedures for call hold 


6.4.0 


6.5.0 


2005-03 


NP#27 


NP-050105 


060 


1 


Corrections to AMR codec parameters 


6.5.0 


6.6.0 


2005-06 


CP#28 


CP-050038 


064 


1 


Call Hold corrections 


6.6.0 


6.7.0 


2005-09 


CP#29 


CP-050451 


073 


4 


Coding of Called Party Number 


6.7.0 


7.0.0 


2005-09 


CP#29 


CP-050451 


074 


1 


Mapping of Hop Counter 


6.7.0 


7.0.0 


2005-09 


CP#29 


CP-050451 


077 


3 


mapping of Called Party Number 


6.7.0 


7.0.0 


2005-12 


CP#30 


CP-050515 


070 


2 


Mapping of codecs 


7.0.0 


7.1.0 


2005-12 


CP#30 


CP-050521 


080 


2 


Clean-up of hanging contexts and terminations 


7.0.0 


7.1.0 


2005-12 


CP#30 


CP-050515 


081 


3 


Interworking of 3PTY and CQNF 


7.0.0 


7.1.0 


2005-12 


CP#30 


CP-050515 


082 


2 


Interworking of ACR 


7.0.0 


7.1.0 


2005-12 


CP#30 


CP-050513 


086 


2 


Support of Tel and SIP URI 


7.0.0 


7.1.0 


2005-12 


CP#30 


CP-050515 


087 


1 


Support of Tel and SIP URImapping of 'restriction by the network' 


7.0.0 


7.1.0 


2005-12 


CP#30 


CP-050514 


088 


2 


IMS Terminating Callflows without preconditions 


7.0.0 


7.1.0 


2005-12 


CP#30 


CP-050514 


089 


2 


IMS Qriginating Callflows without preconditions 


7.0.0 


7.1.0 


2005-12 


CP#30 


CP-050514 


090 


2 


IMS Terminating Procedures without preconditions 


7.0.0 


7.1.0 
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2005-12 


CP#30 


CP-050514 


091 


3 


IMS Originating Procedures without preconditions 


7.0.0 


7.1.0 


2005-12 


CP#30 


CP-050512 


093 


3 


Handling of Overlap signalling 


7.0.0 


7.1.0 


2005-12 


CP#30 


CP-050516 


094 


1 


Incorporating of TR 24.819 fixed broadband access impacts into TS 
29.163 


7.0.0 


7.1.0 


2005-12 


CP#30 


CP-050659 


095 


1 


Interworking of FCI and BCI 


7.0.0 


7.1.0 


2006-03 


CP#31 


CP-060056 


096 




Clarfication of lAM to SIP Invite message mapping 


7.1.0 


7.2.0 


2006-03 


CP#31 


CP-060056 


098 


1 


SCTP changes 


7.1.0 


7.2.0 


2006-03 


CP#31 


CP-060046 


100 




Bearer Released use with TDM Circuit 


7.1.0 


7.2.0 


2006-03 


CP#31 


CP-060046 


105 




488 status code 


7.1.0 


7.2.0 


2006-03 


CP#31 


CP-060047 


109 


4 


Interworking RTP timestamps and luFP frame numbers 


7.1.0 


7.2.0 


2006-03 


CP#31 


CP-060129 


110 




Status Code 433 for ACR 


7.1.0 


7.2.0 


2006-06 


CP#32 


CP-060223 


111 


3 


Removal of editor's notes on open points for Mn Procedures for non- 
preconditions Callflows 


7.2.0 


7.3.0 


2006-06 


CP#32 


CP-060223 


112 


4 


Add related references to T.38 


7.2.0 


7.3.0 


2006-06 


CP#32 


CP-060220 


116 


1 


Bearer Released use with IMS terminations 


7.2.0 


7.3.0 


2006-06 


CP#32 


CP-060223 


117 


1 


Reference to the correct value of Anonymous URI 


7.2.0 


7.3.0 


2006-09 


CP#33 


CP-060429 


119 


3 


Interworking of REFER 


7.3.0 


7.4.0 


2006-09 


CP#33 


CP-060429 


120 


2 


Interworking of Nature of connection indicators 


7.3.0 


7.4.0 


2006-09 


CP#33 


CP-060429 


121 


3 


Interworking of CPC 


7.3.0 


7.4.0 


2006-09 


CP#33 


CP-060429 


122 


2 


MGCF Procedures for non-preconditions Callflows 


7.3.0 


7.4.0 


2006-09 


CP#33 


CP-060429 


123 


1 


Suitable references for Status Code 433 for ACR 


7.3.0 


7.4.0 


2006-09 


CP#33 


CP-060424 


125 


2 


Echo Control Device indication in ACM/CPG 


7.3.0 


7.4.0 


2006-09 


CP#33 


CP-060437 


126 




Missing description of CUG service 


7.3.0 


7.4.0 


2006-09 


CP#33 


CP-060425 


128 


2 


Missing procedures toward IMS Terminations 


7.3.0 


7.4.0 


2006-09 


CP#33 


CP-060471 


129 


1 


Changes due to non-precondition setup 


7.3.0 


7.4.0 


2006-12 


CP#34 


CP-060626 


130 


4 


Interworking of USI 


7.4.0 


7.5.0 


2006-12 


CP#34 


CP-060734 


131 


1 


Handling of emergency call in MGCF 


7.4.0 


7.5.0 


2006-12 


CP#34 


CP-060632 


132 




Clarifications on Supplementary service handling 


7.4.0 


7.5.0 


2006-12 


CP#34 


CP-060633 


133 


1 


Unknown User Identity 


7.4.0 


7.5.0 


2007-03 


CP#35 


CP-070095 


136 


1 


Scope update for Multimedia interworking 


7.5.0 


7.6.0 


2007-03 


CP#35 


CP-070095 


137 


4 


Multimedia interworking 


7.5.0 


7.6.0 


2007-03 


CP#35 


CP-070103 


138 


1 


Adding CS data call interworking to interworking capabilities 
overview table 1 


7.5.0 


7.6.0 


2007-06 


CP#36 


CP-070412 


140 


3 


Media oriented negotiation acceleration 


7.6.0 


7.7.0 


2007-06 


CP#36 


CP-070412 


141 


6 


Mn Procedures of Multimedia Interworking 


7.6.0 


7.7.0 


2007-06 


CP#36 


CP-070413 


142 


2 


Change Table 1 1 


7.6.0 


7.7.0 


2007-06 


CP#36 


CP-070413 


143 


1 


correction of cpc interworking 


7.6.0 


7.7.0 


2007-06 


CP#36 


CP-070413 


144 


1 


The interworking of the PSTN ECT service 


7.6.0 


7.7.0 


2007-06 


CP#36 


CP-070413 


145 


2 


Mapping of HLC 


7.6.0 


7.7.0 


2007-06 


CP#36 


CP-070413 


146 


1 


Mistake in the handling of sending ringing tone 


7.6.0 


7.7.0 


2007-06 


CP#36 


CP-070413 


147 


1 


Support of all types of TMR 


7.6.0 


7.7.0 


2007-06 


CP#36 


CP-070483 


148 


5 


IMS communication service identifier 


7.6.0 


7.7.0 


2007-06 


CP#36 


CP-070412 


149 


1 


Editorial Corrections 


7.6.0 


7.7.0 


2007-06 


CP#36 


CP-070415 


151 


2 


Taking P-Early-Media header into account in 29.163 


7.6.0 


7.7.0 


2007-06 


CP#36 


CP-070416 


153 


2 


IP realm connection indication 


7.6.0 


7.7.0 


2007-09 


CP#37 


CP-070562 


155 


2 


Essential corrections to P-Early-Media header procedures 


7.7.0 


7.8.0 


2007-09 


CP#37 


CP-070562 


157 


2 


Action of requesting the absent CLI 


7.7.0 


7.8.0 


2007-09 


CP#37 


CP-070561 


160 


2 


7 Khz Mapping 


7.7.0 


7.8.0 


2007-09 


CP#37 


CP-070551 


162 


2 


Correction to Mn procedures 


7.7.0 


7.8.0 


2007-09 


CP#37 


CP-070553 


163 


2 


Maximum Multiplex Level for H.223 negotiation 


7.7.0 


7.8.0 


2007-09 


CP#37 


CP-070553 


164 




Multiplex tables 


7.7.0 


7.8.0 


2007-09 


CP#37 


CP-070553 


165 




Flow correction: removal of demux- and connection properties 


7.7.0 


7.8.0 


2007-09 


CP#37 


CP-070562 


166 


2 


Interworking of SIP History-Info header 


7.7.0 


7.8.0 


2007-09 


CP#37 


CP-070563 


173 


2 


Mn Procedures to support P-early-media SIP header 


7.7.0 


7.8.0 


2007-09 


CP#37 


CP-070553 


174 


3 


Corrections to Multimedia Mn Procedures 


7.7.0 


7.8.0 


2007-09 


CP#37 


CP-070686 


168 


3 


Corrections to Multimedia Mn Procedures 


7.8.0 


8.0.0 


2007-09 


CP#37 


CP-070686 


169 


3 


Add support for equal Carrier Access procedures 


7.8.0 


8.0.0 


2007-12 


CP#38 


CP-070721 


178 




Inactivity timout procedures - Alignment to Mc profile 


8.0.0 


8.1.0 


CP-070723 


179 




Termination heartbeat - Alignment to Mc profile 


CP-070722 


181 




Update P-Early-Media Reference 


CP-070724 


182 




Addition of interworking for Sub-adressing 


CP-070725 


185 




Add support for ISUP to SIP interworking for carrier-based routeing 


2008-03 


CP#39 


CP-080047 


196 


3 


SIP XML transit specific element interworking 


8.1.0 


8.2.0 


2008-03 


CP#39 


CP-080047 


197 


3 


Progress Indicator mapping 


8.1.0 


8.2.0 


2008-03 


CP#39 


CP-080047 


198 


4 


Procedure for Fall back interworking 


8.1.0 


8.2.0 


2008-03 


CP#39 


CP-080045 


199 


3 


Addition of UUS Interworking description 


8.1.0 


8.2.0 


2008-03 


CP#39 


CP-080041 


201 




Reason Header in Responses 


8.1.0 


8.2.0 


2008-03 


CP#39 


CP-080042 


203 


1 


Corrections for facsimile interworking 


8.1.0 


8.2.0 


2008-03 


CP#39 


CP-080039 


205 


2 


Correction to Call setup if multimedia call can not be recognized in 
an unambiguous manner 


8.1.0 


8.2.0 


2008-05 


CP#40 


CP-080297 


207 


1 


Additions of subclause for TISPAN CDIV supplemetary service 
interworking 


8.2.0 


8.3.0 
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2008-05 


CP#40 


CP-080297 


208 


1 


Additions of subclause for TISPAN CONFsupplemetary service 
interworl<ing 


8.2.0 


8.3.0 


2008-05 


CP#40 


CP-080297 


209 


2 


Additions of subclause for TISPAN TIP/TIR supplemetary service 
interworking 


8.2.0 


8.3.0 


2008-05 


CP#40 


CP-080297 


210 


1 


Additions of subclause for CUG simulation service for TISPAN 
supplemetary 


8.2.0 


8.3.0 


2008-05 


CP#40 


CP-080297 


211 


2 


Additions of subclausefor MCID simulation service for TISPAN 
supplemetary 


8.2.0 


8.3.0 


2008-05 


CP#40 


CP-080297 


212 


4 


Inclusion of common procedure in TS 29.163 


8.2.0 


8.3.0 


2008-05 


CP#40 


CP-080297 


215 


4 


TMR and Fallback mapping 


8.2.0 


8.3.0 


2008-05 


CP#40 


CP-080294 


217 


3 


Interworking of Terminal Portability 


8.2.0 


8.3.0 


2008-05 


CP#40 


CP-080294 


218 


2 


Satellite indicator mapping 


8.2.0 


8.3.0 


2008-05 


CP#40 


CP-080291 


219 


1 


MONA Mn Procedures 


8.2.0 


8.3.0 


2008-05 


CP#40 


CP-080290 


221 


2 


DTMF Encoding 


8.2.0 


8.3.0 


2008-05 


CP#40 


CP-080290 


223 


1 


DTMF Mn Procedures 


8.2.0 


8.3.0 


2008-09 


CP#41 


CP-080556 


226 




Correction to the communication diversion service 


8.3.0 


8.4.0 


2008-09 


CP#41 


CP-080552 


228 


3 


Correction to supplementary service sections in TS 29.1 63 


8.3.0 


8.4.0 


2008-09 


CP#41 


CP-080563 


231 


1 


Mapping of TMU 


8.3.0 


8.4.0 


2008-09 


CP#41 


CP-080563 


233 


1 


Progress Indicator mapping 


8.3.0 


8.4.0 


2008-09 


CP#41 


CP-080563 


235 


1 


Editorial changes 


8.3.0 


8.4.0 


2008-09 


CP#41 


CP-080554 


241 


2 


CCBS interworking 


8.3.0 


8.4.0 


2008-09 


CP#41 


CP-080559 


242 


1 


Improvements to MTSI and 3G324M interworking 


8.3.0 


8.4.0 


2008-09 


CP#41 


CP-080552 


244 


2 


Coding of the b=line in SDP information 


8.3.0 


8.4.0 


2008-09 


CP#41 


CP-080555 


245 


2 


CW interworking 


8.3.0 


8.4.0 


2008-09 


CP#41 


CP-080556 


246 


1 


Mapping of Call Rejected 


8.3.0 


8.4.0 


2008-12 


CP#42 


CP-080761 


248 


6 


Message body to transfer digits 


8.4.0 


8.5.0 


2008-12 


CP#42 


CP-080761 


249 


2 


l-MGCF: Overlap signalling procedures 


8.4.0 


8.5.0 


2008-12 


CP#42 


CP-080761 


250 


4 


0-MGCF: Overlap signalling additions 


8.4.0 


8.5.0 


2008-12 


CP#42 


CP-080753 


251 


1 


Satellite indicator 


8.4.0 


8.5.0 


2008-12 


CP#42 


CP-080769 


252 


1 


Revision Annex F3 


8.4.0 


8.5.0 


2008-12 


CP#42 


CP-080771 


255 


1 


Update reference for DAI Parameter for the "tel" URI 


8.4.0 


8.5.0 


2008-12 


CP#42 


CP-080771 


256 


2 


Editorial Corrections 


8.4.0 


8.5.0 


2008-12 


CP#42 


CP-080771 


262 


3 


Correction of the mapping tables for interwoking call forwarding 
CDIV 


8.4.0 


8.5.0 


2008-12 


CP#42 


CP-080771 


263 


1 


Addition of interworking for Sub-addressing 


8.4.0 


8.5.0 


2008-12 


CP#42 


CP-080753 


265 


1 


Update to reference for ACR 


8.4.0 


8.5.0 


2008-12 


CP#42 


CP-080771 


266 


1 


Corrections to References 


8.4.0 


8.5.0 


2008-12 


CP#42 


CP-080771 


267 


2 


Miscellaneous corrections 


8.4.0 


8.5.0 


2008-12 


CP#42 


CP-080766 


268 


3 


Clarification of RTCP messages usage in the inter-working gateways 


8.4.0 


8.5.0 


2008-12 


CP#42 


CP-080762 


272 


1 


CCBS Interworking 


8.4.0 


8.5.0 


2008-12 


CP#42 


CP-080763 


273 


4 


CDIV alignment with 3GPPP2 


8.4.0 


8.5.0 


2008-12 


CP#42 


CP-080763 


274 


1 


Modification of Ti/w2 timer values 


8.4.0 


8.5.0 


2008-12 


CP#42 


CP-080763 


275 


2 


Receipt of INVITE with no SDP (offer) 


8.4.0 


8.5.0 


2008-12 


CP#42 


CP-080770 


276 




MONA corrections 


8.4.0 


8.5.0 


2008-12 


CP#42 


CP-080771 


278 


2 


Addition of IP interface type 


8.4.0 


8.5.0 


2009-03 


CP#43 


CP-090095 


281 


1 


Handle the SIP URI in History-Info 


8.5.0 


8.6.0 


2009-03 


CP#43 


CP-090228 


282 


1 


Miscellaneous corrections in History-Info mapping tables 


8.5.0 


8.6.0 


2009-03 


CP#43 


CP-090095 


283 


1 


Map priv-value of session and header in History-Info 


8.5.0 


8.6.0 


2009-03 


CP#43 


CP-090094 


285 


1 


Progress Indicator mapping 


8.5.0 


8.6.0 


2009-03 


CP#43 


CP-090094 


286 


2 


Supplementary service reference and naming correction 


8.5.0 


8.6.0 


2009-03 


CP#43 


CP-090078 


290 


2 


Corrections to Tables 12 and 16 


8.5.0 


8.6.0 


2009-03 


CP#43 


CP-090217 


291 


4 


Clarification of CDIV mapping 


8.5.0 


8.6.0 


2009-05 


CP#44 


CP-090349 


292 


2 


Missing MONA procedures in stage 2 


8.6.0 


8.7.0 


2009-05 


CP#44 


CP-090348 


293 




Correction on CDIV mapping 


8.6.0 


8.7.0 


2009-05 


CP#44 


CP-090348 


295 


2 


Correction of ACM and CPG sending procedures 


8.6.0 


8.7.0 


2009-05 


CP#44 


CP-090348 


296 


1 


Renumbering of duplicated table 17c 


8.6.0 


8.7.0 


2009-05 


CP#44 


CP-090487 


297 


2 


l-MGCF procedures for MCID mapping 


8.6.0 


8.7.0 


2009-05 


CP#44 


CP-090332 


300 


2 


Correction of the procedure for setting of Continuity Indicator in 
subclause 7.3.3.1.2.2 


8.6.0 


8.7.0 


2009-05 


CP#44 


CP-090344 


302 


1 


Mapping between GSM HR codec and SDP parameters 


8.6.0 


8.7.0 


2009-09 


CP#45 


CP-090568 


306 


1 


Correcting references to H.324 regarding MONA 


8.7.0 


8.8.0 


2009-09 


CP#45 


CP-090579 


307 




Correction of the mapping of PSTN XML body with ISUP parameters 
to ACM, REL and CON 


8.7.0 


8.8.0 


2009-12 


CP#46 


CP-090835 


313 


5 


Correction of CPC parameter mapping 


8.8.0 


8.9.0 


2009-12 


CP#46 


CP-090848 


314 




CDIV redirection parameters mapping 


8.8.0 


8.9.0 


2009-12 


CP#46 


CP-090848 


319 


5 


Support interworking of Call Forwarding information 


8.8.0 


8.9.0 


2009-12 


CP#46 


CP-090834 


322 


3 


Reference to Reason Header in Responses 


8.8.0 


8.9.0 


2009-12 


CP#46 


CP-090835 


324 


2 


Interworking ISUP OLI parameter 


8.8.0 


8.9.0 


2009-12 


CP#46 


CP-090835 


326 


1 


Mapping for Communication Barring Service 


8.8.0 


8.9.0 


2009-12 


CP#46 


CP-090834 


330 


2 


Mapping of From header at 0-MGCF 


8.8.0 


8.9.0 


2009-12 


CP#46 


CP-090855 


311 


1 


CS-IMS interworking for SRVCC emergency calls 


8.9.0 


9.0.0 


2009-12 


CP#46 


CP-090849 


315 


1 


Fallback to speech for CS originated multimedia call 


8.9.0 


9.0.0 



£75/ 



3GPP TS 29.163 version 9.13.0 Release 9 



311 



ETSI TS 129 163 V9.13.0 (2013-04) 



2009-12 


CP#46 


CP-090849 


327 


4 


Mapping of ISUP Cause values in CPG or ACIVI to SIP reason 
header in provisional responses 


8.9.0 


9.0.0 


2010-03 


CP#47 


CP-1 00071 


335 


1 


Handling of SDP bandwidth attribute 


9.0.0 


9.1.0 


2010-03 


CP#47 


CP-1 00081 


337 


1 


MCID Interworking 


9.0.0 


9.1.0 


2010-03 


CP#47 


CP-1 00079 


339 


2 


Interworking of RTCP and H.245 messages 


9.0.0 


9.1.0 


2010-03 


CP#47 


CP-1 00081 


342 


1 


Correction of mapping between ISUP CSI and dai parameter 


9.0.0 


9.1.0 


2010-03 


CP#47 


CP-1 00081 


344 




Duplicate table number 


9.0.0 


9.1.0 


2010-03 


CP#47 


CP-1 00071 


347 




Corrections to Release Procedures 


9.0.0 


9.1.0 


2010-03 


CP#47 


CP-1 00081 


349 




Corrections to Release Procedures when MGCF supports PSTN 
XML body 


9.0.0 


9.1.0 


2010-03 


CP#47 


CP-1 00071 


352 




Corrections to Table 6 


9.0.0 


9.1.0 


2010-03 


CP#47 


CP-1 00071 


355 


1 


Corrections to through-connection procedures 


9.0.0 


9.1.0 


2010-03 


CP#47 
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